This patch implements transparent fail over from synthetic NIC to
SR-IOV virtual function NIC in Hyper-V environment. It is a better
alternative to using bonding as is done now. Instead, the receive and
transmit fail over is done internally inside the driver.
Using bonding driver has lots of issue
Add some background documentation on netvsc device options
and limitations.
Signed-off-by: Stephen Hemminger
---
Documentation/networking/netvsc.txt | 63 +
MAINTAINERS | 1 +
2 files changed, 64 insertions(+)
create mode 100644 Docum
No longer needed, now all managed by transparent VF logic.
Signed-off-by: Stephen Hemminger
---
tools/hv/bondvf.sh | 255 -
1 file changed, 255 deletions(-)
delete mode 100755 tools/hv/bondvf.sh
diff --git a/tools/hv/bondvf.sh b/tools/hv/bond
This patch set changes how SR-IOV Virtual Function devices are managed
in the Hyper-V network driver. This version is rebased onto current net-next.
Background
In Hyper-V SR-IOV can be enabled (and disabled) by changing guest settings
on host. When SR-IOV is enabled a matching PCI device is hot p
On Tue, Aug 01, 2017 at 11:30:01PM +0200, Boris Brezillon wrote:
> Hi Greg,
>
> Le Tue, 1 Aug 2017 10:51:33 -0700,
> Greg Kroah-Hartman a écrit :
>
> > On Tue, Aug 01, 2017 at 12:48:01PM +0200, Boris Brezillon wrote:
> > > > > +static DEFINE_MUTEX(i3c_core_lock);
> > > > > +
> > > > > +void i3c_
On Tue, Aug 01, 2017 at 11:30:01PM +0200, Boris Brezillon wrote:
> > > > No release type? Oh that's bad bad bad and implies you have never
> > > > removed a device from your system as the kernel would have complained
> > > > loudly at you.
> > >
> > > You got me, never tried to remove a device
From: Stephen Hemminger
Date: Mon, 31 Jul 2017 16:45:21 -0700
> This patch set changes how SR-IOV Virtual Function devices are managed
> in the Hyper-V network driver. It was part of earlier bundle, but
> is now updated.
I think you need to do a rebase. I just merged net into net-next and
this
Le Tue, 1 Aug 2017 19:27:03 +0200,
Wolfram Sang a écrit :
> > I'm surprised they didn't allow for slave clock stretching when
> > communicating with a legacy i2c device, it will prohibit use of a rather
> > large class of devices. :(
>
> Yes, but I3C is push/pull IIRC.
It is.
>
> > As for i
Hi Greg,
Le Tue, 1 Aug 2017 10:51:33 -0700,
Greg Kroah-Hartman a écrit :
> On Tue, Aug 01, 2017 at 12:48:01PM +0200, Boris Brezillon wrote:
> > > > +static DEFINE_MUTEX(i3c_core_lock);
> > > > +
> > > > +void i3c_bus_lock(struct i3c_bus *bus, bool exclusive)
> > > > +{
> > > > + if (exclus
On Tue, Aug 1, 2017 at 5:14 PM, Boris Brezillon
wrote:
> On Tue, 1 Aug 2017 16:22:21 +0200 Arnd Bergmann wrote:
>> On Tue, Aug 1, 2017 at 3:58 PM, Boris Brezillon
>> wrote:
>> > On Tue, 1 Aug 2017 15:34:14 +0200
>> > Boris Brezillon wrote:
>> >> On Tue, 1 Aug 2017 15:11:44 +0200
>> >> Arnd Berg
On 08/01/2017 10:35 AM, Prarit Bhargava wrote:
On 08/01/2017 01:00 PM, John Stultz wrote:
On Tue, Aug 1, 2017 at 5:55 AM, Prarit Bhargava wrote:
printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock
timestamp to printk messages. The local hardware clock loses time each
da
On Tue, 1 Aug 2017, Prarit Bhargava wrote:
> On 08/01/2017 01:00 PM, John Stultz wrote:
> > Its been asked already, but I've not yet seen an answer.
>
> Sorry for missing this.
>
> > Is there a reason your not also adding PRINTK_TIME_BOOT here (which to
> > me would be more generally useful then
On 08/01/2017 12:29 PM, Luis R. Rodriguez wrote:
Thanks for the previous comments re: enum & kdoc'ifying. I will apply them to
v3.
>
> And since you are kdoc'ifying consider later adding proper rst format docs
> for printk and then pegging this kdoc entry into it. Unfortunately I only
> se
On Tue, Aug 01, 2017 at 07:03:03PM +0200, Michal Hocko wrote:
> On Tue 01-08-17 16:25:48, Roman Gushchin wrote:
> > On Tue, Aug 01, 2017 at 04:54:35PM +0200, Michal Hocko wrote:
> [...]
> > > I would reap out the oom_kill_process into a separate patch.
> >
> > It was a separate patch, I've merged
On Tue, Aug 01, 2017 at 12:48:01PM +0200, Boris Brezillon wrote:
> > > +static DEFINE_MUTEX(i3c_core_lock);
> > > +
> > > +void i3c_bus_lock(struct i3c_bus *bus, bool exclusive)
> > > +{
> > > + if (exclusive)
> > > + down_write(&bus->lock);
> > > + else
> > > + down_read(&bus->lock
On Tue, Aug 1, 2017 at 10:35 AM, Prarit Bhargava wrote:
>
>
> On 08/01/2017 01:00 PM, John Stultz wrote:
>> Is there a reason your not also adding PRINTK_TIME_BOOT here (which to
>> me would be more generally useful then REAL or MONO)?
>
> REAL has been useful to me in debug cases where events on
On 08/01/2017 01:00 PM, John Stultz wrote:
> On Tue, Aug 1, 2017 at 5:55 AM, Prarit Bhargava wrote:
>> printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock
>> timestamp to printk messages. The local hardware clock loses time each
>> day making it difficult to determine exac
> I'm surprised they didn't allow for slave clock stretching when
> communicating with a legacy i2c device, it will prohibit use of a rather
> large class of devices. :(
Yes, but I3C is push/pull IIRC.
> As for interrupts you are always free to wire up an out-of-band
> interrupt like before. :)
On Tue 01-08-17 16:25:48, Roman Gushchin wrote:
> On Tue, Aug 01, 2017 at 04:54:35PM +0200, Michal Hocko wrote:
[...]
> > I would reap out the oom_kill_process into a separate patch.
>
> It was a separate patch, I've merged it based on Vladimir's feedback.
> No problems, I can divide it back.
It
On Tue, Aug 1, 2017 at 5:55 AM, Prarit Bhargava wrote:
> printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock
> timestamp to printk messages. The local hardware clock loses time each
> day making it difficult to determine exactly when an issue has occurred in
> the kernel log
On 07/31/2017 04:42 PM, Wolfram Sang wrote:
>
>> Actually, that's the first option I considered, but I3C and I2C are
>> really different. I'm not talking about the physical layer here, but
>> the way the bus has to be handled by the software layer. Actually, I
>> thing the I3C bus is philosophical
On Tue, Aug 01, 2017 at 08:55:28AM -0400, Prarit Bhargava wrote:
> diff --git a/arch/x86/configs/x86_64_defconfig
> b/arch/x86/configs/x86_64_defconfig
> index 4a4b16e56d35..23da8e5297a1 100644
> --- a/arch/x86/configs/x86_64_defconfig
> +++ b/arch/x86/configs/x86_64_defconfig
> @@ -283,7 +283,13
Michael Ellerman writes:
> Thiago Jung Bauermann writes:
>> Ram Pai writes:
> ...
>>> +
>>> + /* We got one, store it and use it from here on out */
>>> + if (need_to_set_mm_pkey)
>>> + mm->context.execute_only_pkey = execute_only_pkey;
>>> + return execute_only_pkey;
>>> +}
>>
On Tue, Aug 01, 2017 at 04:54:35PM +0200, Michal Hocko wrote:
> On Wed 26-07-17 14:27:16, Roman Gushchin wrote:
> [...]
> > +static long memcg_oom_badness(struct mem_cgroup *memcg,
> > + const nodemask_t *nodemask)
> > +{
> > + long points = 0;
> > + int nid;
> > +
> > +
On Tue, 1 Aug 2017 17:01:08 +0200
Wolfram Sang wrote:
> > I do not know of any real devices as of today (all my tests have been
> > done with a dummy/fake I3C slaves emulated with a slave IP),
>
> I see.
>
> > spec clearly describe what legacy/static addresses are for and one of
> > their use
On Tue, 1 Aug 2017 16:22:21 +0200
Arnd Bergmann wrote:
> On Tue, Aug 1, 2017 at 3:58 PM, Boris Brezillon
> wrote:
> > On Tue, 1 Aug 2017 15:34:14 +0200
> > Boris Brezillon wrote:
> >> On Tue, 1 Aug 2017 15:11:44 +0200
> >> Arnd Bergmann wrote:
> >> > On Tue, Aug 1, 2017 at 2:29 PM, Boris B
> I do not know of any real devices as of today (all my tests have been
> done with a dummy/fake I3C slaves emulated with a slave IP),
I see.
> spec clearly describe what legacy/static addresses are for and one of
> their use case is to connect an I3C device on an I2C bus and let it act
> as an
On Tue, Aug 01, 2017 at 10:07:40AM -0400, Jintack Lim wrote:
> On Sun, Jul 30, 2017 at 3:59 PM, Christoffer Dall wrote:
> > On Tue, Jul 18, 2017 at 11:58:30AM -0500, Jintack Lim wrote:
> >> Nested virtualizaion is in use only if all three conditions are met:
> >> - The architecture supports nested
On Wed 26-07-17 14:27:16, Roman Gushchin wrote:
[...]
> +static long memcg_oom_badness(struct mem_cgroup *memcg,
> + const nodemask_t *nodemask)
> +{
> + long points = 0;
> + int nid;
> +
> + for_each_node_state(nid, N_MEMORY) {
> + if (nodemask &&
Add a resource managed version of irq_sim_init(). This can be
conveniently used in device drivers.
Signed-off-by: Bartosz Golaszewski
---
Documentation/driver-model/devres.txt | 1 +
include/linux/irq_sim.h | 4
kernel/irq_sim.c | 43
Shrink the driver by removing the code dealing with dummy interrupts
and replacing it with calls to the irq_sim API.
Signed-off-by: Bartosz Golaszewski
---
drivers/gpio/Kconfig | 2 +-
drivers/gpio/gpio-mockup.c | 77 +-
2 files changed, 8 inser
Some frameworks (e.g. iio, gpiolib) use irq_work to implement simulated
interrupts that can be 'fired' from process context when needed and
requested just like normal interrupts. This is useful for testing and
development purposes.
Currently this code is reimplemented by every user. This series
pr
Implement a simple, irq_work-based framework for simulating
interrupts. Currently the API exposes routines for initializing and
deinitializing the simulator object, enqueueing the interrupts and
retrieving the allocated interrupt numbers based on the offset of the
dummy interrupt in the simulator s
On Tue, 1 Aug 2017 16:12:18 +0200
Wolfram Sang wrote:
> > > The second way is to have a number of #ifdef and complex
> > > Kconfig dependencies for the driver to only register the
> > > device_driver objects for the buses that are enabled. This
> > > is also doable, but everyone gets the logic wr
On Tue, Aug 1, 2017 at 3:58 PM, Boris Brezillon
wrote:
> On Tue, 1 Aug 2017 15:34:14 +0200
> Boris Brezillon wrote:
>> On Tue, 1 Aug 2017 15:11:44 +0200
>> Arnd Bergmann wrote:
>> > On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon
>> > wrote:
> I just realized I forgot to add a "depends on I2C"
On Tue, 1 Aug 2017 07:09:10 -0400
Sean Anderson wrote:
> Documentation/filesystems/Locking no longer reflects current locking
> semantics. i_mutex is no longer used for locking, and has been superseded
> by i_rwsem. Additionally, ->iterate_shared() was not documented.
>
> Signed-off-by: Sean And
v3:
1. Added Documentation for new flag
2. Changed the flag description
v2:
1. Added DMA_PREP_CMD flag and used the same for BAM DMA
command descriptor
2. Removed custom mapping API patches
v1:
https://www.spinics.net/lists/dmaengine/msg12009.html
These patches mainly add the support for Q
QCOM BAM also supports command descriptor which allows the SW to
create descriptors of type command which does not generate any
data transmissions but configures registers in the peripheral.
In command descriptor the 32bit address point to the start of
the command block which holds the command elem
If DMA_PREP_CMD flag is passed in prep_slave_sg then peripheral
driver has passed the data is in BAM command descriptor format
and BAM driver should set CMD bit for each of the HW descriptors.
Signed-off-by: Abhishek Sahu
---
drivers/dma/qcom/bam_dma.c | 6 +-
1 file changed, 5 insertions(+)
Some of the DMA controllers are capable of issuing the commands
to peripheral by the DMA. These commands can be list of register
reads/writes and its different from normal data reads/writes.
This patch adds new flag DMA_PREP_CMD in DMA API which tells
the driver that the data passed to DMA API is c
> > The second way is to have a number of #ifdef and complex
> > Kconfig dependencies for the driver to only register the
> > device_driver objects for the buses that are enabled. This
> > is also doable, but everyone gets the logic wrong the first time.
>
> Hm, I understand now why you'd prefer
On Sun, Jul 30, 2017 at 4:00 PM, Christoffer Dall wrote:
> On Tue, Jul 18, 2017 at 11:58:46AM -0500, Jintack Lim wrote:
>> When HCR.NV bit is set, eret instructions trap to EL2 with EC code 0x1A.
>> Emulate eret instructions by setting pc and pstate.
>
> It may be worth noting in the commit messag
On Sun, Jul 30, 2017 at 3:59 PM, Christoffer Dall wrote:
> On Tue, Jul 18, 2017 at 11:58:34AM -0500, Jintack Lim wrote:
>> To support the virtual EL2 execution, we need to maintain the EL2
>> special registers such as SPSR_EL2, ELR_EL2 and SP_EL2 in vcpu context.
>>
>> Note that SP_EL2 is not acce
On Sun, Jul 30, 2017 at 3:59 PM, Christoffer Dall wrote:
> On Tue, Jul 18, 2017 at 11:58:30AM -0500, Jintack Lim wrote:
>> Nested virtualizaion is in use only if all three conditions are met:
>> - The architecture supports nested virtualization.
>> - The kernel parameter is set.
>> - The userspace
On Sun, Jul 30, 2017 at 3:59 PM, Christoffer Dall wrote:
> On Tue, Jul 18, 2017 at 11:58:30AM -0500, Jintack Lim wrote:
>> Nested virtualizaion is in use only if all three conditions are met:
>> - The architecture supports nested virtualization.
>> - The kernel parameter is set.
>> - The userspace
On Tue, 1 Aug 2017 15:34:14 +0200
Boris Brezillon wrote:
> On Tue, 1 Aug 2017 15:11:44 +0200
> Arnd Bergmann wrote:
>
> > On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon
> > wrote:
> > > On Tue, 1 Aug 2017 14:00:05 +0200
> > > Arnd Bergmann wrote:
> >
> > >> Another argument for a co
On Sun, Jul 30, 2017 at 3:59 PM, Christoffer Dall wrote:
> On Tue, Jul 18, 2017 at 11:58:28AM -0500, Jintack Lim wrote:
>> Add a new kernel parameter(kvm-arm.nested) to enable KVM/ARM nested
>> virtualization support. This kernel parameter on arm architecture is
>> ignored since nested virtualizat
On Tue, 1 Aug 2017 15:11:44 +0200
Arnd Bergmann wrote:
> On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon
> wrote:
> > On Tue, 1 Aug 2017 14:00:05 +0200
> > Arnd Bergmann wrote:
>
> >> Another argument for a combined bus would be devices that
> >> can be attached to either i2c and i3c, depend
On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon
wrote:
> On Tue, 1 Aug 2017 14:00:05 +0200
> Arnd Bergmann wrote:
>> Another argument for a combined bus would be devices that
>> can be attached to either i2c and i3c, depending on the host
>> capabilities.
>
> Hm, that's already the case, isn't i
printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock
timestamp to printk messages. The local hardware clock loses time each
day making it difficult to determine exactly when an issue has occurred in
the kernel log, and making it difficult to determine how kernel and
hardware i
On Tue, 1 Aug 2017 14:00:05 +0200
Arnd Bergmann wrote:
> On Mon, Jul 31, 2017 at 11:15 PM, Boris Brezillon
> wrote:
> > Hi Arnd,
> >
> > Le Mon, 31 Jul 2017 22:16:42 +0200,
> > Arnd Bergmann a écrit :
> >
> >> On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon
> >> wrote:
> >> > Add core inf
On Mon, Jul 31, 2017 at 11:15 PM, Boris Brezillon
wrote:
> Hi Arnd,
>
> Le Mon, 31 Jul 2017 22:16:42 +0200,
> Arnd Bergmann a écrit :
>
>> On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon
>> wrote:
>> > Add core infrastructure to support I3C in Linux and document it.
>>
>> > - I2C backward compa
On Tue, Aug 01, 2017 at 07:03:35AM -0400, Jintack Lim wrote:
> Hi Christoffer,
>
> On Mon, Jul 31, 2017 at 8:59 AM, Christoffer Dall wrote:
> > On Tue, Jul 18, 2017 at 11:59:04AM -0500, Jintack Lim wrote:
> >> Forward CPACR_EL1 traps to the virtual EL2 if virtual CPTR_EL2 is
> >> configured to tr
On Tue, 2017-08-01 at 07:09 -0400, Sean Anderson wrote:
> Documentation/filesystems/Locking no longer reflects current locking
> semantics. i_mutex is no longer used for locking, and has been superseded
> by i_rwsem. Additionally, ->iterate_shared() was not documented.
>
> Signed-off-by: Sean Ande
Documentation/filesystems/Locking no longer reflects current locking
semantics. i_mutex is no longer used for locking, and has been superseded
by i_rwsem. Additionally, ->iterate_shared() was not documented.
Signed-off-by: Sean Anderson
---
v2: changed 'yes's to 'exclusive's when describing i_rws
Hi Christoffer,
On Mon, Jul 31, 2017 at 8:59 AM, Christoffer Dall wrote:
> On Tue, Jul 18, 2017 at 11:59:04AM -0500, Jintack Lim wrote:
>> Forward CPACR_EL1 traps to the virtual EL2 if virtual CPTR_EL2 is
>> configured to trap CPACR_EL1 accesses from EL1.
>>
>> This is for recursive nested virtua
On 8/1/2017 12:27 PM, Christoph Hellwig wrote:
On Tue, Aug 01, 2017 at 12:20:36PM +0200, Roberto Sassu wrote:
This patch introduces a parser for RPM packages. It extracts the digests
from the RPMTAG_FILEDIGESTS header section and converts them to binary data
before adding them to the hash table.
Hi Christoffer,
On Mon, Jul 31, 2017 at 9:00 AM, Christoffer Dall wrote:
> Hi Jintack,
>
> On Tue, Jul 18, 2017 at 11:58:26AM -0500, Jintack Lim wrote:
>> Nested virtualization is the ability to run a virtual machine inside another
>> virtual machine. In other words, it’s about running a hypervis
Hello Greg,
On Mon, 31 Jul 2017 18:40:21 -0700
Greg Kroah-Hartman wrote:
> On Mon, Jul 31, 2017 at 06:24:47PM +0200, Boris Brezillon wrote:
> > Add core infrastructure to support I3C in Linux and document it.
> >
> > This infrastructure is not complete yet and will be extended over
> > time.
>
On Tue, Aug 01, 2017 at 12:20:36PM +0200, Roberto Sassu wrote:
> This patch introduces a parser for RPM packages. It extracts the digests
> from the RPMTAG_FILEDIGESTS header section and converts them to binary data
> before adding them to the hash table.
>
> The advantage of this data type is tha
This patch introduces a parser for RPM packages. It extracts the digests
from the RPMTAG_FILEDIGESTS header section and converts them to binary data
before adding them to the hash table.
The advantage of this data type is that verifiers can determine who
produced that data, as headers are signed b
Userspace applications will be able to load digest lists by supplying
their metadata.
Digest list metadata are:
- DATA_ALGO: algorithm of the digests to be uploaded
- DATA_DIGEST: digest of the file containing the digest list
- DATA_SIGNATURE: signature of the file containing the digest list
- DA
Users must be given an option to discard any constraints set by
bootloaders. For example, consider that a constraint is set for the LCD
controller's supply and the LCD driver isn't loaded by the kernel. If
the user doesn't need to use the LCD device, then he shouldn't be forced
to honour the constr
Hi Greg,
Here is V3 of the boot constraints core based on the feedbacks I have
received during V2. This tested on real hardware (Qcom dragonboard 410c)
with a display controller configured from bootloader to display a flash
screen. Obviously it doesn't work seamlessly without this series and
works
64 matches
Mail list logo
