From: Pavel Begunkov
> Sent: 13 December 2020 22:33
>
> On 11/12/2020 02:01, Al Viro wrote:
> > On Thu, Nov 19, 2020 at 05:12:44PM +, Pavel Begunkov wrote:
> >> On 19/11/2020 17:03, Christoph Hellwig wrote:
> >>> On Thu, Nov 19, 2020 at 03:29:43PM +, Pavel Begunkov wrote:
> The proble
From: Pawel Laszczak
> Sent: 14 December 2020 11:05
>
> Patch fixes the following warnings:
...
> cdns3-ep0.c:367: sparse: warning: restricted __le16 degrades to integer
...
> diff --git a/drivers/usb/cdns3/cdns3-ep0.c b/drivers/usb/cdns3/cdns3-ep0.c
> index b0390fe9a396..9a17802275d5 100644
> ---
From: Philipp Gerlesberger
> Sent: 14 December 2020 11:04
>
> You can sum up the two lines, because the maximum line length of
> 100 columns is not exceeded.
IIRC the 80 column limit is preferred.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
From: Philipp Gerlesberger
> Sent: 14 December 2020 11:02
>
> Logical continuations should be on the previous line
>
> Co-developed-by: Andrey Khlopkov
> Signed-off-by: Andrey Khlopkov
> Signed-off-by: Philipp Gerlesberger
> ---
> drivers/staging/media/atomisp/pci/runtime/queue/src/queue.c | 4
From: Bean Huo
> Sent: 14 December 2020 20:20
>
> From: Bean Huo
>
> Current EM macro definition, we use stringize operator '#', which turns
> the argument it precedes into a quoted string. Thus requires the symbol
> of __print_symbolic() should be the string corresponding to the name of
> the
From: Pavel Begunkov
> Sent: 15 December 2020 00:20
>
> iov_iter_advance() is heavily used, but implemented through generic
> iteration. As bvecs have a specifically crafted advance() function, i.e.
> bvec_iter_advance(), which is faster and slimmer, use it instead.
>
> Signed-off-by: Pavel Begun
From: Andrew Cooper
> Sent: 26 November 2020 23:52
>
> On 26/11/2020 19:15, Andy Lutomirski wrote:
> > On Thu, Nov 26, 2020 at 11:07 AM Lukas Bulwahn
> > wrote:
> >> On Thu, Nov 26, 2020 at 6:16 PM Andrew Cooper
> >> wrote:
> >>> On 26/11/2020 11:54, Lukas Bulwahn wrote:
> Commit 1e5de182
From: Thomas Zimmermann
> Sent: 20 November 2020 13:42
...
> I did a diff from v5.10-rc4 to drm-tip to look for suspicious changes.
> Some candidates are
>
>8e3784dfef8a ("drm/ast: Reload gamma LUT after changing primary
> plane's color format")
Ok, that one fixes the screen colours (etc).
So
From: Waiman Long
> Sent: 20 November 2020 17:04
>
> On 11/20/20 8:11 AM, David Laight wrote:
> > From: Waiman Long
> >> Sent: 19 November 2020 18:40
> > ...
> >> My own testing also show not too much performance difference when
> >> removing re
From: Johan Hovold
> Sent: 20 November 2020 12:50
>
> On Fri, Nov 20, 2020 at 07:25:03PM +0800, tiantao (H) wrote:
> > 在 2020/11/20 16:23, Johan Hovold 写道:
> > > On Thu, Nov 19, 2020 at 05:01:29PM +0800, Tian Tao wrote:
> > >> The code has been in a irq-disabled context since it is hard IRQ. There
From: Davidlohr Bueso
> Sent: 20 November 2020 21:38
>
> On Fri, 20 Nov 2020, David Laight wrote:
> >I got massive performance improvements from changing a driver
> >we have to use mutex instead of the old semaphores (the driver
> >was written a long time ago).
> >
From: David Howells
> Sent: 22 November 2020 13:33
>
> Linus Torvalds wrote:
>
> > - I worry a bit about the indirect call overhead and spectre v2.
>
> I don't know enough about how spectre v2 works to say if this would be a
> problem for the ops-table approach, but wouldn't it also affect the
et, and branch
> _anywhere_, and the attack vectors can poison the BTB (branch target
> buffer), so our mitigation for that is that every single indirect
> branch isn't predicted at all (using "retpoline").
>
> So a conditional branch takes zero cycles when predic
From: David Howells
> Sent: 21 November 2020 14:14
>
> Switch to using a table of operations. In a future patch the individual
> methods will be split up by type. For the moment, however, the ops tables
> just jump directly to the old functions - which are now static. Inline
> wrappers are prov
From: Joe Perches
> Reduce text a bit by using static const.
If you want to save a few bytes remove the pointers.
(and the fixed RAM text to get below 7 chars).
eg:
> - const char *ramtypetext2[] = { "SDR SDRAM", "SDR SGRAM",
> - "DDR SDRAM", "DDR SGRAM" }
From: Joe Perches [
> On Mon, 2014-02-24 at 10:26 +0000, David Laight wrote:
> > From: Joe Perches
> > > Reduce text a bit by using static const.
> >
> > If you want to save a few bytes remove the pointers.
> > (and the fixed RAM text to get belo
From: Keith Packard
> The Lenovo OneLink dock includes a USB ethernet adapter using the
> AX88179 chip, but with a different USB ID. Add this new USB id to the
> driver so that it will autodetect the adapter correctly.
>
> Signed-off-by: Keith Packard
> Tested-by: Carl Worth
> ---
> drivers/net
> > I think you need 3 instructions, move a 0, conditionally move a 1
> > then add. I suspect it won't be a win!
Or, with an appropriately unrolled loop, for each word:
zero %eax, cmove a 1 to %al
cmove a 1 to %ah
shift %eax left, cmove a 1 to %al
cmove a 1 to %ah,
> > I just did a diff of registers in exynos 4210 and 4212 PHY drivers [1]
> > and couldn't find that big a difference in register layout. Of course
> > there are a few changes in HSIC bit fields and PHYFSEL but that's only
> > minimal and could well be handled in a single driver.
> >
> > [1] -> ht
From: Zhouyi Zhou
> not frequently changing components should share same cachelines
>
> Signed-off-by: Zhouyi Zhou
> ---
> include/net/netns/conntrack.h | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/include/net/netns/conntrack.h b/include/net/netns/conn
From: Hayes Wang
> For slow CPU, the frequent bulk transfer would cause poor throughput.
> One solution is to increase the timeout of the aggregation. It let
> the hw could complete the bulk transfer later and fill more packets
> into the buffer. Besides, it could reduce the frequency of the bulk
>
From: Hayes Wang
...
I should have spotted this before.
> /* USB_RX_EARLY_AGG */
> -#define EARLY_AGG_SUPPER 0x0e832981
> +#define EARLY_AGG_SUPER rx_buf_sz - 1522) / 4) << 16) | \
> + (u32)(CONFIG_RTL8152_EARLY_AGG_TIMEOUT_SUPER <= 0 ? 85 * 125 : \
> + min(CONFIG_RTL8152_EA
From: Hayes Wang
> Support scatter gather and TSO.
>
> Adjust the tx checksum function and set the max gso size to fix the
> size of the tx aggregation buffer.
There is little point supporting TSO unless the usb host controller
supports arbitrary aligned scatter-gather.
All you do is require that
From: hayeswang
> David Laight [mailto:david.lai...@aculab.com]
> > Sent: Tuesday, March 04, 2014 8:12 PM
> > To: 'Hayes Wang'; net...@vger.kernel.org
> > Cc: nic_s...@realtek.com; linux-kernel@vger.kernel.org;
> > linux-...@vger.kernel.org
> > Subject
From: Eric Dumazet
> On Tue, 2014-03-04 at 14:35 +0000, David Laight wrote:
>
> > Does that mean you are splitting the 64k 'ethernet packet' from TCP
> > is software? I've looked at the ax88179 where the hardware can do it.
> >
> > Is there really a g
From: Bjorn Helgaas
> With -Werror=array-bounds, gcc v4.7.x warns that in phy_find_valid(), the
> settings[] "array subscript is above array bounds", I think because idx is
> a signed integer and if the caller supplied idx < 0, we pass the guard but
> still reference out of bounds.
Not rejecting t
From: Bjorn Helgaas
> On Wed, Mar 5, 2014 at 2:10 AM, David Laight wrote:
> > From: Bjorn Helgaas
> >> With -Werror=array-bounds, gcc v4.7.x warns that in phy_find_valid(), the
> >> settings[] "array subscript is above array bounds", I think because idx is
&g
From: Bjorn Helgaas
> I'm stumped. phy_find_valid() is static and only called from one
> place. The 'idx' argument is always the result of phy_find_setting(),
> which should always return something between 0 and
> ARRAY_SIZE(settings), so I don't see any way idx can be < 0.
>
> I stripped this d
From: Sukadev Bhattiprolu
> When checking whether a bit representing a register is set in
> sample_regs, a 64-bit mask, use 64-bit value (1LL).
>
> Signed-off-by: Sukadev Bhattiprolu
> ---
> tools/perf/util/unwind.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a
From: David Herrmann
> The name_assign_type attribute gives hints where the interface name of a
> given net-device comes from. Three different values are currently defined:
> NET_NAME_ENUM:
> This is the default. The ifname is provided by the kernel with an
> enumerated suffix. Names may
From: beh...@converseincode.com
> From: Mark Charlebois
>
> Replaced non-standard C use of Variable Length Arrays In Structs (VLAIS) in
> xt_repldata.h with a C99 compliant flexible array member and then calculated
> offsets to the other struct members. These other members aren't referenced by
>
From: Behan Webster
> On 03/18/14 02:41, David Laight wrote:
> > From: beh...@converseincode.com
> >> From: Mark Charlebois
> >>
> >> Replaced non-standard C use of Variable Length Arrays In Structs (VLAIS) in
> >> xt_repldata.h with a
From: beh...@converseincode.com
> From: Mark Charlebois
>
> Replaced non-standard C use of Variable Length Arrays In Structs (VLAIS) in
> xt_repldata.h with a C99 compliant flexible array member and then calculated
> offsets to the other struct members. These other members aren't referenced by
>
From: beh...@converseincode.com
> Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
> compliant equivalent. This is the original VLAIS struct.
>
> struct {
> struct aead_request req;
> u8 priv[crypto_aead_reqsize(tfm)];
> } aead_req;
>
>
From: Kevin Hao
> Sent: 20 March 2014 11:48
> To: Scott Wood
> Cc: linuxppc-...@lists.ozlabs.org; Chenhui Zhao; jason@freescale.com;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040
>
> On Tue, Mar 18, 2014 at 06:18:54PM -0500, Scott Wo
From: Scott Wood [mailto:scottw...@freescale.com]
> On Thu, 2014-03-20 at 11:59 +0000, David Laight wrote:
> > I tried to work out what the 'twi, isync' instructions were for (in
> > in_le32()).
> > The best I could come up with was to ensure a synchronous bu
From: Michal Simek
> From: Peter Crosthwaite
>
> The packet completion interrupts for TX and RX should be serviced before
> the packets are consumed. This ensures against the degenerate case when a
> new completion interrupt is raised after the handler has exited but before
> the interrupts are c
From: Emil Goode
> > > int rndis_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
> > > {
> > > + /* This check is no longer done by usbnet */
> > > + if (skb->len < dev->net->hard_header_len)
> > > + return 0;
> > > +
> >
> > Wouldn't it be better to test against ETH_HLEN, since that is
From: Of Emil Goode
> This patch removes a generic hard_header_len check from the usbnet
> module that is causing dropped packages under certain circumstances
> for devices that send rx packets that cross urb boundaries.
>
> One example is the AX88772B which occasionally send rx packets that
> cro
From: walt
> On 01/21/2014 01:51 AM, David Laight wrote:
> > From: Sarah Sharp
> >> On Mon, Jan 20, 2014 at 11:21:14AM +, David Laight wrote:
> > ...
> >>> A guess...
> >>>
> >>> In queue_bulk_sg_tx() try calling xhci_v1_0_td_remai
> From: walt
...
> Thanks Sarah. dmesg0 is from the diagnostic patch only. dmesg1 has all
> three patches applied. Some of the messages in dmesg1 fell off the end of
> the kernel buffer, so I may need to make the buffer larger next time but
> I'll need a reminder of how to do it.
>
> As you sus
The dmesg contains:
[ 538.728064] EXT4-fs warning (device dm-0): ext4_end_bio:316: I/O error
writing to inode 23330865 (offset 0 size 8388608 starting block 812628)
An 8MB transfer will need at least 128 ring entries (TRB) even if the request
is a single contiguous memory block.
Are you using
> From: Sarah Sharp
> On Tue, Jan 07, 2014 at 03:57:00PM -0800, walt wrote:
> > On 01/07/2014 01:21 PM, Sarah Sharp wrote:
> >
> > > Can you please try the attached patch, on top of the previous three
> > > patches, and send me dmesg?
> >
> > Hi Sarah, I just now finished running 0001-More-debuggin
> From: Alan Stern
>
> This may be a foolish question, but why is xhci-hcd using no-op TRBs in
> the first place?
Because it can't write in a link TRB because other parts of the
code use link TRBs to detect the end of the ring.
The problem is that it can't put a link TRB in the middle of
a chain
> From: Alan Stern
> On Wed, 8 Jan 2014, David Laight wrote:
>
> > > From: Alan Stern
> > >
> > > This may be a foolish question, but why is xhci-hcd using no-op TRBs in
> > > the first place?
> >
> > Because it can't write in a link T
> From: walt
...
> I'm still wondering if I'm suffering from hardware quirks. From the
> first day I installed my usb3 adapter card and the usb3 disk docking
> station I've noticed some quirky behavior.
Ah - this isn't an 'on chip' usb3 adapter.
Some kind of PCIe card ?
> e.g. I boot the machine
From: Shahed Shaikh
> Adding netdev.
>
> > -Original Message-
> > From: Martin Kaiser,,, [mailto:mar...@reykholt.kaiser.cx] On Behalf Of
> > Martin Kaiser
> > Sent: Thursday, January 09, 2014 9:29 PM
> > To: Himanshu Madhani; Rajesh Borundia
> > Cc: linux-kernel; triv...@kernel.org
> > Sub
From: David Miller
...
> > On Thu, Jan 9, 2014 at 12:26 PM, Neal Cardwell wrote:
> >> On Thu, Jan 9, 2014 at 3:16 PM, Dan Williams
> >> wrote:
> >>> net_dma was the only external user so this can become local to tcp.c
> >>> again.
> >> ...
> >>> -void tcp_cleanup_rbuf(struct sock *sk, int copied
From: walt
> > In the meantime, try this patch, which is something of a long shot.
>
> No difference. But I notice the code enables the TRB quirk only if the
> xhci_version is specifically 0x95. My debug messages claim that "xHCI
> doesn't need link TRB QUIRK" so I'm wondering if adding my asmed
> From: Of Roger Quadros
> With u-boot 2013.10, USB devices are sometimes not detected
> on OMAP4 Panda. To make us independent of what bootloader does
> with the USB Host module, we must RESET it to get it to a known
> good state. This patch Soft RESETs the USB Host module.
...
> +++ b/drivers/mfd
From: Mathias Nyman
> This is an attempt to re-work and solve the issues in xhci command
> queue management that Sarah has descibed earlier:
>
> Right now, the command management in the xHCI driver is rather ad-hock.
> Different parts of the driver all submit commands, including interrupt
> handli
From: walt
> On 01/09/2014 03:50 PM, Sarah Sharp wrote:
>
> >>> On Tue, Jan 07, 2014 at 03:57:00PM -0800, walt wrote:
> >>
> >> I've wondered if my xhci problems might be caused by hardware quirks, and
> >> wondering why I seem to be the only one who has this problem.
> >>
> >> Maybe I could "take
From: Mathias Nyman
...
> > The fact that you are having to allocate memory ion an ISR ought also to be
> > ringing alarm bells.
>
> It did.
> Other options are as you said to use a 'software command ring'. Either
> just pre-allocate a full command ring (64 trbs * sizeof(struct
> xhci_command)),
> > @@ -1637,7 +1637,7 @@ static int sync_thread_master(void *data)
> > continue;
> > }
> > while (ip_vs_send_sync_msg(tinfo->sock, sb->mesg) < 0) {
> > - int ret = __wait_event_interruptible(*sk_sleep(sk),
>
> So ideally there's be a c
> > I've done this in the past so that the code sleeps interruptibly
> > unless there is a signal pending - which would cause it to return
> > early.
> >
> > /* Tell scheduler we are going to sleep... */
> > if (signal_pending(current))
> > /* We don't want waking immediately (again
> Sure, I modified the code so that we only prefetched 2 cache lines ahead, but
> only if the overall length of the input buffer is more than 2 cache lines.
> Below are the results (all counts are the average of 100 iterations of the
> csum operation, as previous tests were, I just omitted that
> Implement instr_is_load_store_2_06() to detect whether a given instruction
> is one of the fixed-point or floating-point load/store instructions in the
> POWER Instruction Set Architecture v2.06.
...
> +int instr_is_load_store_2_06(const unsigned int *instr)
> +{
> + unsigned int op, upper, l
> On Tue, 2013-10-15 at 14:29 +, Kelleter, Günther wrote:
> > Addresses are BCD encoded, not ASCII. x25_addr_ntoa got it right.
> []
> > Wrong length calculation leads to rejection of CALL ACCEPT packets.
> []
> > diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
> []
> > @@ -98,7 +98,7 @@ int x
> From: Eric Dumazet [mailto:eric.duma...@gmail.com]
> On Tue, 2013-11-19 at 09:02 -0500, Mark Lord wrote:
> > On 13-11-19 05:04 AM, David Laight wrote:
> > >> From: Mark Lord
> > ..
> > >> except the ax88179_178a driver still does not work in linux
> From: Eric Dumazet [mailto:eric.duma...@gmail.com]
> On Tue, 2013-11-19 at 14:43 +, David Laight wrote:
>
> > It isn't directly a TSO problem.
> > There has always been a bug in the xhci driver for fragmented buffers.
> > TSO just means it is given a lot o
> Wouldn't it be simpler and safer to just do this unconditionally? Sure,
> you need it for DWC3 because the controller refuses to do an OUT transfer
> at all if the transfer size is less than maxpacketsize. But it's possible
> that other controllers allow the transfer, and it works in most cases,
> The parallel ALU design of this patch seems OK at first glance, but it means
> that two parallel operations are both trying to set/clear both the overflow
> and carry flags of the EFLAGS register of the *CPU* (not the ALU). So, either
> some CPU in the past had a set of overflow/carry flags per
> /me wonders if rearranging the instructions into this order:
> adcq 0*8(src), res1
> adcq 1*8(src), res2
> adcq 2*8(src), res1
Those have to be sequenced.
Using a 64bit lea to add 32bit quantities should avoid the
dependencies on the flags register.
However you'd need to get 3 of those active t
...
> and then I also wanted to try using both xmm and ymm registers and doing
> 64bit adds with 32bit numbers across multiple xmm/ymm registers as that
> should parallel nicely. David, you mentioned you've tried this, how did
> your experiment turn out and what was your method? I was planning on
> > + {0x674bf11d, 0x0038, 0x0542, 0x0af6d466, 0xd8b6e4c1,
> > 0xf6e93d6c},
>
> these could be
>
> + {0x674bf11d, 0x38, 0x542, 0x0af6d466, 0xd8b6e4c1, 0xf6e93d6c},
Or even:
#define X(a, b, c, d, e, f) {0x##a, 0x##b, 0x##c, 0x##d, 0x##e. 0x##f}
X(674bf11d, 38, 542, 0af6d466,
> "For instance, your producer must issue a "memory barrier" instruction
> after writing the data to shared memory and before inserting it on
> the queue; likewise, your consumer must issue a memory barrier
> instruction after removing an item from the queue and before reading
> from its me
> How would you suggest replacing the jumps in this case? I agree it would be
> faster here, but I'm not sure how I would implement an increment using a
> single
> conditional move.
I think you need 3 instructions, move a 0, conditionally move a 1
then add. I suspect it won't be a win!
If you d
> But "broken" compiler is much wider issue to be deeply discussed in this
> thread. I'm pretty sure that kernel have tons of very subtle
> code that actually creates locks and memory ordering. Such code
> usually just use the "barrier()" approach to tell gcc not to combine
> or move memory access
> From: David Miller
>
> > According to Documentation/networking/driver.txt the ndo_start_xmit
> > method should not return NETDEV_TX_BUSY under normal circumstances.
> > Stop the transmit queue when tx_ring is full.
...
> You should be instead preventing the transmit method from being invoked
>
> From: Roger Quadros [mailto:rog...@ti.com]
> On 11/29/2013 03:17 PM, David Laight wrote:
...
> >> + timeout = jiffies + msecs_to_jiffies(100);
> >> + while (!(usbhs_read(omap->uhh_base, OMAP_UHH_SYSSTATUS)
> >> + & OMAP_UHH_SYSSTATUS
> > In normal operation, IP-A sends INIT to IP-X, IP-X returns INIT_ACK to
> > IP-A. IP-A then sends HB to IP-X, IP-X then returns HB_ACK to IP-A. In
> > the meantime, IP-B sends HB to IP-Y and IPY returns HB_ACK.
> >
> > In case of the path between IP-A and IP-X is broken, IP-B sends INIT
> > to I
> From: fre...@asix.com.tw
...
> - skb = __netdev_alloc_skb_ip_align(dev->net, size, flags);
> + if (dev->driver_info->flags & FLAG_HW_IPALIGN)
> + skb = __netdev_alloc_skb(dev->net, size, flags);
> + else
> + skb = __netdev_alloc_skb_ip_align(dev->net, size, fla
> From: Freddy Xin
> On 2013年12月13日 18:36, David Laight wrote:
> >> From: fre...@asix.com.tw
> > ...
> >> - skb = __netdev_alloc_skb_ip_align(dev->net, size, flags);
> >> + if (dev->driver_info->flags & FLAG_HW_IPALIGN)
> >&
From: David Miller
> From: Tom Gundersen
> Date: Thu, 17 Jul 2014 10:06:04 +0200
>
> > @@ -192,8 +193,10 @@ int ieee802154_add_iface(struct sk_buff *skb, struct
> > genl_info *info)
> > if (devname[nla_len(info->attrs[IEEE802154_ATTR_DEV_NAME]) - 1]
> > !=
From: Eric Dumazet
> On Thu, 2014-01-16 at 00:23 +0100, Daniel Borkmann wrote:
>
> > @@ -1220,7 +1219,7 @@ static unsigned int fanout_demux_hash(struct
> > packet_fanout *f,
> > struct sk_buff *skb,
> > unsigned int num)
> > {
>
From: Chen-Yu Tsai
> snprintf should be passed the complete size of the buffer, including
> the space for '\0'. The previous code resulted in the *_reset and
> *_shutdown strings being truncated.
...
> diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
...
> - snprintf(rfkill->res
From: Hannes Frederic Sowa
...
> +/**
> + * trim - perform a reciprocal multiplication in order to "clamp" a
> + *value into range [0, ep_ro), where the upper interval
> + *endpoint is right-open. This is useful, e.g. for accessing
> + *a index of an array containing ep_ro e
From: Hannes Frederic Sowa
> On Thu, Jan 16, 2014 at 10:37:37AM -0600, Christoph Lameter wrote:
> > On Thu, 16 Jan 2014, Daniel Borkmann wrote:
> >
> > > - * or else the performance is slower than a normal divide.
> > > - */
> > > -extern u32 reciprocal_value(u32 B);
> > > +struct reciprocal_value
From: walt
> Oy, Sarah! ;) I put the ASMedia adapter in my older amd64 machine, and, well,
> the stupid thing Just Works(TM) with kernel 3.12.7! (Yes, with the same disk
> docking station, too.)
>
> I can't believe the adapter works perfectly in a different computer. Have you
> seen this kind o
From:
> On 01/17/2014 06:34 AM, David Laight wrote:
>
> > Can you try the patch I posted that stops the ownership on LINK TRBs
> > being changed before that on the linked-to TRB?
>
> Sadly, the patch didn't fix the ASMedia lockup behavior, however :(
>
> I
From: walt
> On 01/17/2014 06:34 AM, David Laight wrote:
>
> > Can you try the patch I posted that stops the ownership on LINK TRBs
> > being changed before that on the linked-to TRB?
>
> Please disregard my earlier post about the patch not applying cleanly.
> That wa
From: Sarah Sharp
> On Mon, Jan 20, 2014 at 11:21:14AM +0000, David Laight wrote:
...
> > A guess...
> >
> > In queue_bulk_sg_tx() try calling xhci_v1_0_td_remainder() instead
> > of xhci_td_remainder().
>
> Why? Walt has a 0.96 xHCI host controller, and the for
From: Aaron Tomlin
> Currently in the event of a stack overrun a call to schedule()
> does not check for this type of corruption. This corruption is
> often silent and can go unnoticed. However once the corrupted
> region is examined at a later stage, the outcome is undefined
> and often results in
From: Chuck Ebbert
> David Laight wrote:
>
> > From: Aaron Tomlin
> > > Currently in the event of a stack overrun a call to schedule()
> > > does not check for this type of corruption. This corruption is
> > > often silent and can go unnoticed. How
From: Kees Cook
> This makes the size argument a const, since it is always populated by
> the caller.
There is almost no point making parameters 'const.
('const foo *' makes sense).
> Additionally double-checks to make sure the copy_from_user
> can never overflow, keeping CONFIG_DEBUG_STRICT_USER
From: Hannes Frederic
> On Mo, 2014-09-29 at 12:41 -0700, Kees Cook wrote:
> > On Mon, Sep 29, 2014 at 4:04 AM, David Laight
> > wrote:
> > > From: Kees Cook
> > >> This makes the size argument a const, since it is always populated by
> > >>
From: Hannes Frederic
> On Di, 2014-09-30 at 08:20 +0000, David Laight wrote:
> > From: Hannes Frederic
> > > On Mo, 2014-09-29 at 12:41 -0700, Kees Cook wrote:
> > > > On Mon, Sep 29, 2014 at 4:04 AM, David Laight
> > > > wrote:
> > > > >
From: David Miller
> From: Santosh Shilimkar
> Date: Thu, 25 Sep 2014 13:48:36 -0400
>
> > +static inline int gbe_phy_link_status(struct gbe_slave *slave)
> > +{
> > + if (!slave->phy)
> > + return 1;
> > +
> > + if (slave->phy->link)
> > + return 1;
> > +
> > + return 0
From: Rickard Strandqvist
...
> Replacing strncpy with strlcpy to avoid strings that lacks null terminate.
...
> diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> index 644e6ab..d4fe8ac 100644
> --- a/drivers/net/can/usb/peak_usb/pcan_usb_c
From: Marc Kleine-Budde [
> On 09/15/2014 10:28 AM, David Laight wrote:
> > From: Rickard Strandqvist
> > ...
> >> Replacing strncpy with strlcpy to avoid strings that lacks null terminate.
> > ...
> >> diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_cor
From: Rickard Strandqvist
> > 2014-09-15 10:47 GMT+02:00 David Laight :
...
> > Or:
> > char name[sizeof netdev->name];
> > memcpy(name, netdev->name, sizeof netdev->name);
> >
...
> I liked the variant:
> char name[sizeof(netdev->name)];
From: Mathias Nyman
> This reverts commit 3804fad45411b48233b48003e33a78f290d227c8.
>
> This commit, together with commit 247bf557273dd775505fb9240d2d152f4f20d304
> "xhci 1.0: Limit arbitrarily-aligned scatter gather." were
> origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a devi
From: Mathias Nyman
> This reverts commit 247bf557273dd775505fb9240d2d152f4f20d304.
You need to revert further.
Just don’t set hcd->self.no_sg_constraint ever - since it just
doesn't work.
That will stop the ax88179_178a driver sending fragmented packets.
With the check for aligned non-terminal f
From: Alan Stern
> On Fri, 7 Mar 2014, David Laight wrote:
>
> > From: Mathias Nyman
> > > This reverts commit 3804fad45411b48233b48003e33a78f290d227c8.
> > >
> > > This commit, together with commit 247bf557273dd775505fb9240d2d152f4f20d304
> > &
From: Alan Stern
> On Fri, 7 Mar 2014, David Laight wrote:
>
> > From: Mathias Nyman
> > > This reverts commit 247bf557273dd775505fb9240d2d152f4f20d304.
> >
> > You need to revert further.
> > Just don?t set hcd->self.no_sg_constraint ever - since it ju
From:
> On Fri, 7 Mar 2014, David Laight wrote:
>
> > From: Alan Stern
> > > On Fri, 7 Mar 2014, David Laight wrote:
> > >
> > > > From: Mathias Nyman
> > > > > This reverts commit 3804fad45411b48233b48003e33a78f290d227
From: j...@joshtriplett.org
> On Fri, Mar 07, 2014 at 01:02:44PM -0800, Joe Perches wrote:
> > On Fri, 2014-03-07 at 15:41 -0500, David Miller wrote:
> > > From: Alistair Popple
> > > Date: Thu, 6 Mar 2014 14:52:25 +1100
> > >
> > > > + out_be32(dev->reg, in_be32(dev->reg) | WKUP_ETH_RGMIIE
From: David Miller
> From: Linus Torvalds
> Date: Mon, 10 Mar 2014 19:02:18 -0700
>
> > I would generally suggest that people only use "bool" for function
> > return types, and absolutely nothing else. Seriously.
>
> I think it makes sense for function arguments too.
'bool' doesn't necessarily
From: Yijing Wang
> This patchset rename the current pci_is_bridge() to pci_has_subordinate(),
> and introduce a new pci_is_bridge() which determine pci bridge by check
> dev->hdr_type. The new one is more accurate. PCIe Spec define the pci
> device is a bridge by the dev->hdr_type = 0x01 || 0x02.
From: Of Parag Warudkar
> I see a continuous flood of below messages on plugging in/using my USB
> token. (The comp code wasn't in the original message - I added it.) From
> what I can tell the device continues to work as expected.
>
> Should the warning be disabled for COMP_SHORT_TX like it is fo
701 - 800 of 1947 matches
Mail list logo
