On Sep 12, 2014, at 3:40 PM, Andrew Morton wrote:
> On Thu, 11 Sep 2014 23:39:36 +0200 Michal Nazarewicz
> wrote:
>
>> Because min and max macros use the same variable names no matter
>> how many times they are called (or how deep the nesting of their
>> calls), each time min or max calls are
Michal,
On Sep 12, 2014, at 4:37 PM, Michal Nazarewicz wrote:
> On Fri, Sep 12 2014, Andrew Morton wrote:
>> On Thu, 11 Sep 2014 23:39:36 +0200 Michal Nazarewicz
>> wrote:
>>
>>> Because min and max macros use the same variable names no matter
>>> how many times they are called (or how deep
> On Sep 4, 2015, at 2:07 AM, David Laight wrote:
>
>> I find them useful as syntactic sugar. We have not used them a lot, but
>> there are cases in our crypto
>> handling code where we have fixed size array inputs/outputs and there we
>> opted to use them. They make
>> it easy to remember
> On Sep 7, 2015, at 4:02 AM, David Laight wrote:
>
> Feed:
> int bar(int (*f)[10]) { return sizeof *f; }
> into cc -O2 -S and look at the generated code - returns 40 not 4.
Yes, indeed it does. And with clang too. I guess I was too easily discouraged
when looking for a workable syntax some
> On Sep 9, 2015, at 9:07 PM, Jarod Wilson wrote:
>
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
> b/drivers/net/ethernet/intel/igb/igb_main.c
> index e174fbb..a5e0022 100644
> --- a/drivers/net/ethernet/intel/igb/igb_main.c
> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> @@
Alex,
> On Sep 11, 2015, at 11:16 AM, Alex Williamson
> wrote:
>
> RFC - Is this something we should do?
Superficially this looks pretty good. I need to think harder to be sure of the
details.
> Should we consider providing
> similar emulation through PCI sysfs to allow lspci to also make
Gerry,
> On Aug 9, 2015, at 1:15 AM, Jiang Liu wrote:
>
> Alex Deucher, Mark Rustad and Alexander Holler reported a regression
> with the latest v4.2-rc4 kernel, which breaks some SATA controllers.
> With multi-MSI capable SATA controllers, only the first port works,
> all other ports times out
The warning appears in W=2 builds. I had another way to silence it by using
diagnostic control macros, but those macros were not accepted. Using a single
designated initialization also silences it.
Sent from my iPhone
> On Oct 17, 2014, at 8:26 AM, "Christoph Hellwig" wrote:
>
>> On Tue, Oct
On Nov 4, 2014, at 7:52 AM, Steven Rostedt wrote:
> From: "Steven Rostedt (Red Hat)"
>
> To allow for the restructiong of the trace_seq code, we need users
> of it to use the helper functions instead of accessing the internals
> of the trace_seq structure itself.
>
> Cc: Mark Rustad
> Cc:
On Nov 4, 2014, at 11:35 AM, Steven Rostedt wrote:
> On Tue, 4 Nov 2014 14:09:54 -0500
> Steven Rostedt wrote:
>
>> On Tue, 4 Nov 2014 17:17:08 +0000
>> "Rustad, Mark D" wrote:
>>
>>> On Nov 4, 2014, at 7:52 AM, Steven Rostedt w
On Oct 21, 2014, at 12:07 PM, Andrew Morton wrote:
> On Sat, 18 Oct 2014 17:39:10 -0700 ebied...@xmission.com (Eric W. Biederman)
> wrote:
>
>> Jeff Kirsher writes:
>>
>>> From: Mark Rustad
>>>
>>> Resolve missing-field-initializers warnings in W=2 builds by
>>> using designated
On Feb 11, 2015, at 2:51 PM, Rasmus Villemoes wrote:
> Since these fmt_* variables are just const char*, and not const
> char[], gcc (and smatch) doesn't to type checking of the arguments to
> the printf functions. Since the linker knows perfectly well to merge
> identical string constants,
Zhouyi Zhou wrote:
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index fee1f29..4926d48 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -2173,8 +2173,7 @@ static int
Greg wrote:
Someday Linux will be a modern OS that just includes IPV6 and forces a
config option to NOT have it.
That'll be great. All the IS_ENABLED_(CONFIG_IPV6) scattered everywhere
is nuts.
Better wait until everyone at least *has* IPv6! I have yet to have IPv6
deployed on any of
On Mar 12, 2017, at 7:02 PM, Kees Cook wrote:
> Are there nominations for most comprehensive changelog of the year? :)
> This is awesome.
Especially for a one-liner! Truly comprehensive and completely relevant.
--
Mark Rustad, Networking Division, Intel Corporation
signature.asc
Description:
Denys Vlasenko wrote:
Users report that under VMWare, er32(TIMINCA) returns zero.
This causes division by zero at init time as follows:
==>incvalue = er32(TIMINCA) & E1000_TIMINCA_INCVALUE_MASK;
for (i = 0; i < E1000_MAX_82574_SYSTIM_REREADS; i++) {
Nicholas Krause wrote:
> This fixes error handling in the function fm10k_setup_tc to properly
> check if the call to the function fm10k_open has failed by returning
> a error and if so return immediately to the caller of the function
> fm10k_setup_tc to properly signal this non recoverable
Ben Hutchings wrote:
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -176,6 +176,8 @@ enum pci_dev_flags {
> PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
> /* Provide indication device is assigned by a Virtual Machine Manager */
> PCI_DEV_FLAGS_ASSIGNED =
Ben Hutchings wrote:
> They're bit masks, not bit numbers, both in 3.2 and upstream. In
> mainline, bits 3-7 have already been assigned to other flags. I don't
> see the need to renumber or write the value differently when
> backporting.
No problem. I just saw the different representations
Some comments below:
K. Y. Srinivasan wrote:
On Hyper-V, the VF/PF communication is a via software mediated path
as opposed to the hardware mailbox. Make the necessary
adjustments to support Hyper-V.
Signed-off-by: K. Y. Srinivasan
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h |
KY Srinivasan wrote:
-Original Message-
From: Rustad, Mark D [mailto:mark.d.rus...@intel.com]
Sent: Thursday, April 14, 2016 4:01 PM
To: KY Srinivasan
Cc: David Miller ; netdev
; linux-kernel@vger.kernel.org;
de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
jasow
KY Srinivasan wrote:
-Original Message-
From: Rustad, Mark D [mailto:mark.d.rus...@intel.com]
Sent: Thursday, April 14, 2016 5:07 PM
To: KY Srinivasan
Cc: David Miller ; netdev
; linux-kernel@vger.kernel.org;
de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
jasow
Jarod Wilson wrote:
I've got reports that the Intel I-218V NIC in Intel NUC5i5RYH systems used
as a PTP slave experiences random ~10 hour clock jumps, which are resolved
if the same workaround for the 82574 and 82583 is employed. Switching from
an if to a select, because the list of NIC types
Benjamin Herrenschmidt wrote:
We may want some kind of "strict" vs. "relaxed" model here to
differenciate the desktop user wanting to give a function to his/her
windows partition and doesn't care about strict isolation vs. the cloud
data center.
I don't think desktop users appreciate hangs
Benjamin Herrenschmidt wrote:
Filtering things to work around bugs in existing guests to avoid crashes
is a different kettle of fish and could be justified but keep in mind that
in most cases a malicious guest will be able to exploit those HW flaws.
Bugs in existing guests is an interesting
Andy Shevchenko wrote:
On Mon, Apr 11, 2016 at 6:27 PM, Sudip Mukherjee
wrote:
From: Sudip Mukherjee
We have a check for card just after dereferencing it. So if it is NULL
we have already dereferenced it before its check. Lets dereference it
after checking card for NULL.
IIUC the code
> On Sep 18, 2015, at 1:11 AM, Jiri Slaby wrote:
>
> On 09/15/2015, 06:12 PM, Shuah Khan wrote:
>>
>>
>> Jiri,
>>
>> I am seeing problems during PCI scans with this patch. I had
>> to boot it in recovery mode once and it is booting fine after
>> that, however, this is a concern
>>
>> Could
> On Sep 29, 2015, at 3:39 PM, Joe Stringer wrote:
>
> @@ -728,8 +727,14 @@ static void ovs_fragment(struct vport *vport, struct
> sk_buff *skb, u16 mru,
> WARN_ONCE(1, "Failed fragment ->%s: eth=%04x, MRU=%d, MTU=%d.",
> ovs_vport_name(vport),
> On Sep 15, 2015, at 10:17 AM, Alex Williamson
> wrote:
>
> Commit 932c435caba8 ("PCI: Add dev_flags bit to access VPD through
> function 0") passes PCI_SLOT(devfn) for the devfn parameter of
> pci_get_slot(). Generally this works because we're fairly well
> guaranteed that a PCIe device is
> On Sep 15, 2015, at 9:24 PM, Alex Williamson
> wrote:
>
> When we quirk a device with PCI_DEV_FLAGS_VPD_REF_F0 we're expecting
> to find a device where all the functions are identical. If we don't
> find that, we don't make VPD accessible through pci_vpd_ops. That
> means that if we quirk
> On Sep 24, 2015, at 11:27 AM, Bjorn Helgaas wrote:
>
> Applied to for-linus for v4.3 with acks from Myron & Mark, thanks!
>
> I removed the stable tag because 932c435caba8 first appeared in
> v4.3-rc1, so it shouldn't appear in any stable kernels yet. Right?
I have seen the patch in some
> On Sep 11, 2015, at 6:11 PM, Rustad, Mark D wrote:
>
> Superficially this looks pretty good. I need to think harder to be sure of
> the details.
This is the first time I've looked at all at any of the vfio code, but this is
still looking good to me. Thanks for taking this on
101 - 132 of 132 matches
Mail list logo
