* Re: [PATCH bpf-next v5 3/7] page_pool: Store the XDP mem id
From: Jesper Dangaard Brouer @ 2022-01-05 11:02 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Jesper Dangaard Brouer,
Ilias Apalodimas, David S. Miller, Jakub Kicinski,
Alexei Starovoitov, Daniel Borkmann, John Fastabend,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
KP Singh
Cc: brouer, netdev, bpf
In-Reply-To: <20220103150812.87914-4-toke@redhat.com>
On 03/01/2022 16.08, Toke Høiland-Jørgensen wrote:
> Store the XDP mem ID inside the page_pool struct so it can be retrieved
> later for use in bpf_prog_run().
>
> Signed-off-by: Toke Høiland-Jørgensen<toke@redhat.com>
> ---
> include/net/page_pool.h | 9 +++++++--
> net/core/page_pool.c | 4 +++-
> net/core/xdp.c | 2 +-
> 3 files changed, 11 insertions(+), 4 deletions(-)
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
^ permalink raw reply
* Re: [PATCH mptcp-next v7 1/4] Squash to "mptcp: implement fastclose xmit path"
From: Matthieu Baerts @ 2022-01-05 11:03 UTC (permalink / raw)
To: Geliang Tang; +Cc: mptcp
In-Reply-To: <20220105105540.GA9181@dhcp-10-157-36-190>
Hi Geliang,
On 05/01/2022 11:55, Geliang Tang wrote:
> On Wed, Jan 05, 2022 at 11:01:59AM +0100, Matthieu Baerts wrote:
>> Hi Geliang,
>>
>> On 05/01/2022 09:50, Geliang Tang wrote:
>>> On Thu, Dec 30, 2021 at 08:16:48PM +0100, Matthieu Baerts wrote:
>>>> From: Geliang Tang <geliang.tang@suse.com>
>>>>
>>>> MP_FAIL could be sent with RST or DSS, and FASTCLOSE can be sent with
>>>> RST too. So we should use a similar xmit logic for FASTCLOSE and
>>>> MP_FAIL in both mptcp_write_options() and mptcp_established_options*().
>>>>
>>>> Cc: Paolo Abeni <pabeni@redhat.com>
>>>> Co-developed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
>>>> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
>>>> Signed-off-by: Geliang Tang <geliang.tang@suse.com>
>>>> ---
>>>> net/mptcp/options.c | 66 ++++++++++++++++++++++++++++-----------------
>>>> 1 file changed, 41 insertions(+), 25 deletions(-)
>>>>
>>>> diff --git a/net/mptcp/options.c b/net/mptcp/options.c
>>>> index c6726e8389ec..9d2c1c9edbe6 100644
>>>> --- a/net/mptcp/options.c
>>>> +++ b/net/mptcp/options.c
>>>> @@ -829,8 +829,12 @@ bool mptcp_established_options(struct sock *sk, struct sk_buff *skb,
>>>>
>>>> if (unlikely(skb && TCP_SKB_CB(skb)->tcp_flags & TCPHDR_RST)) {
>>>> if (mptcp_established_options_fastclose(sk, &opt_size, remaining, opts) ||
>>>> - mptcp_established_options_mp_fail(sk, &opt_size, remaining, opts) ||
>>>> - mptcp_established_options_rst(sk, skb, &opt_size, remaining, opts)) {
>>>> + mptcp_established_options_mp_fail(sk, &opt_size, remaining, opts)) {
>>>> + *size += opt_size;
>>>> + remaining -= opt_size;
>>>> + }
>>>> + /* MP_RST can be used with MP_FASTCLOSE and MP_FAIL if there is room */
>>>> + if (mptcp_established_options_rst(sk, skb, &opt_size, remaining, opts)) {
>>>> *size += opt_size;
>>>> remaining -= opt_size;
>>>> }
>>>> @@ -1257,21 +1261,7 @@ static u16 mptcp_make_csum(const struct mptcp_ext *mpext)
>>>> void mptcp_write_options(__be32 *ptr, const struct tcp_sock *tp,
>>>> struct mptcp_out_options *opts)
>>>> {
>>>> - if (unlikely(OPTION_MPTCP_FAIL & opts->suboptions)) {
>>>> - const struct sock *ssk = (const struct sock *)tp;
>>>> - struct mptcp_subflow_context *subflow;
>>>> -
>>>> - subflow = mptcp_subflow_ctx(ssk);
>>>> - subflow->send_mp_fail = 0;
>>>> -
>>>> - *ptr++ = mptcp_option(MPTCPOPT_MP_FAIL,
>>>> - TCPOLEN_MPTCP_FAIL,
>>>> - 0, 0);
>>>> - put_unaligned_be64(opts->fail_seq, ptr);
>>>> - ptr += 2;
>>>> - }
>>>
>>> Hi Matt,
>>>
>>> Sorry, this patch doesn't work on my test. We write both DSS + MP_FAIL,
>>> but MP_FAIL is lost on the received side. Only DSS is received.
>>>
>>> If we write MP_FAIL + DSS like the orignal code, MP_FAIL and DSS will be
>>> received correctly.
>>>
>>> I haven't figured out why yet.
>>>
>>> Could we just keep this MP_FAIL writting code still at the beginning of
>>> the function just like the orignal code did?
>>
>> Thank you for having tested and reviewed the series!
>>
>> Is this issue here fixed by your patch you sent a couple of minutes ago
>> (mptcp: fix a DSS option writting error)
>>
>> That would make sense as the only thing I did was to send the MP_FAIL
>> after the DSS option.
>>
>> Do you mind if I send a v8 series with your new fix the missing 'ptr +=
>> 2;' below and have the code moving the writing of the MP_FAIL option
>> later in a dedicated commit?
>
> Hi Matt,
>
> I think about it again. How about just using the v2 of this patch
> (https://patchwork.kernel.org/project/mptcp/patch/5a8c6024481d6106c662c3e892ae5e499b4a7f76.1638156809.git.geliang.tang@suse.com/)
> as a squash-to patch (We have reached an agreement on this part), and move
> all the other code in this v7 as a new patch (It still needs to be
> improved)?
Yes, I was thinking about something similar except that we also need to
modify mptcp_write_options() to allow sending a RST and a FC together.
I just made the split and for this afternoon, I'm hoping to launch the
new tests you added and try to understand the issue. But if you prefer I
already sent the v8 I have, I can.
Thank you for the instructions from your previous email!
Cheers,
Matt
--
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net
^ permalink raw reply
* Re: [PATCH v2 3/5] KVM: SVM: fix race between interrupt delivery and AVIC inhibition
From: Maxim Levitsky @ 2022-01-05 11:03 UTC (permalink / raw)
To: Sean Christopherson
Cc: kvm, Jim Mattson, Thomas Gleixner, Joerg Roedel,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), Vitaly Kuznetsov,
Borislav Petkov, linux-kernel, Paolo Bonzini, Dave Hansen,
H. Peter Anvin, Wanpeng Li, Ingo Molnar
In-Reply-To: <YdTPvdY6ysjXMpAU@google.com>
On Tue, 2022-01-04 at 22:52 +0000, Sean Christopherson wrote:
> On Mon, Dec 13, 2021, Maxim Levitsky wrote:
> > If svm_deliver_avic_intr is called just after the target vcpu's AVIC got
> > inhibited, it might read a stale value of vcpu->arch.apicv_active
> > which can lead to the target vCPU not noticing the interrupt.
> >
> > To fix this use load-acquire/store-release so that, if the target vCPU
> > is IN_GUEST_MODE, we're guaranteed to see a previous disabling of the
> > AVIC. If AVIC has been disabled in the meanwhile, proceed with the
> > KVM_REQ_EVENT-based delivery.
> >
> > All this complicated logic is actually exactly how we can handle an
> > incomplete IPI vmexit; the only difference lies in who sets IRR, whether
> > KVM or the processor.
> >
> > Also incomplete IPI vmexit, has the same races as svm_deliver_avic_intr.
> > therefore just reuse the avic_kick_target_vcpu for it as well.
> >
> > Reported-by: Maxim Levitsky <mlevitsk@redhat.com>
>
> Heh, probably don't need a Reported-by for a patch you wrote :-)
Paolo gave me this version, I pretty much sent it as is. We had few iterations
of this patch before though we agreed that the race is finally gone.
>
> > Co-developed-with: Paolo Bonzini <pbonzini@redhat.com>
>
> Co-developed-by: is preferred, and should be accompanied by Paolo's SoB.
First time I use this format, so I didn't knew about this.
>
> > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
> > ---
> > arch/x86/kvm/svm/avic.c | 85 +++++++++++++++++++++++++----------------
> > arch/x86/kvm/x86.c | 4 +-
> > 2 files changed, 55 insertions(+), 34 deletions(-)
> >
> > diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c
> > index 90364d02f22aa..34f62da2fbadd 100644
> > --- a/arch/x86/kvm/svm/avic.c
> > +++ b/arch/x86/kvm/svm/avic.c
> > @@ -289,6 +289,47 @@ static int avic_init_backing_page(struct kvm_vcpu *vcpu)
> > return 0;
> > }
> >
> > +static void avic_kick_target_vcpu(struct kvm_vcpu *vcpu)
> > +{
> > + bool in_guest_mode;
> > +
> > + /*
> > + * vcpu->arch.apicv_active is read after vcpu->mode. Pairs
>
> This should say "must be read", not "is read". It's obvious from the code that
> apicv_active is read second, the comment is there to say that it _must_ be read
> after vcpu->mode.
>
> > + * with smp_store_release in vcpu_enter_guest.
> > + */
> > + in_guest_mode = (smp_load_acquire(&vcpu->mode) == IN_GUEST_MODE);
>
> IMO, it's marginally clear to initialize the bool.
>
> bool in_guest_mode = (smp_load_acquire(&vcpu->mode) == IN_GUEST_MODE);
>
> > + if (READ_ONCE(vcpu->arch.apicv_active)) {
> > + if (in_guest_mode) {
> > + /*
> > + * Signal the doorbell to tell hardware to inject the IRQ if the vCPU
> > + * is in the guest. If the vCPU is not in the guest, hardware will
> > + * automatically process AVIC interrupts at VMRUN.
>
> Might as well wrap these comments at 80 chars since they're being moved. Or
> maybe even better....
>
> /* blah blah blah */
> if (!READ_ONCE(vcpu->arch.apicv_active)) {
> kvm_make_request(KVM_REQ_EVENT, vcpu);
> kvm_vcpu_kick(vcpu);
> return;
> }
>
> if (in_guest_mode) {
> ...
> } else {
> ....
> }
>
> ...so that the existing comments can be preserved as is.
>
> > + *
> > + * Note, the vCPU could get migrated to a different pCPU at any
> > + * point, which could result in signalling the wrong/previous
> > + * pCPU. But if that happens the vCPU is guaranteed to do a
> > + * VMRUN (after being migrated) and thus will process pending
> > + * interrupts, i.e. a doorbell is not needed (and the spurious
> > + * one is harmless).
> > + */
> > + int cpu = READ_ONCE(vcpu->cpu);
> > + if (cpu != get_cpu())
> > + wrmsrl(SVM_AVIC_DOORBELL, kvm_cpu_get_apicid(cpu));
> > + put_cpu();
> > + } else {
> > + /*
> > + * Wake the vCPU if it was blocking. KVM will then detect the
> > + * pending IRQ when checking if the vCPU has a wake event.
> > + */
> > + kvm_vcpu_wake_up(vcpu);
> > + }
> > + } else {
> > + /* Compare this case with __apic_accept_irq. */
>
> Honestly, this comment isn't very helpful. It only takes a few lines to say:
>
> /*
> * Manually signal the event, the __apic_accept_irq() fallback
> * path can't be used if AVIC is disabled after the vector is
> * already queued in the vIRR.
> */
>
> (incorporating more feedback below)
>
> > + kvm_make_request(KVM_REQ_EVENT, vcpu);
> > + kvm_vcpu_kick(vcpu);
> > + }
> > +}
> > +
> > static void avic_kick_target_vcpus(struct kvm *kvm, struct kvm_lapic *source,
> > u32 icrl, u32 icrh)
> > {
> > @@ -304,8 +345,10 @@ static void avic_kick_target_vcpus(struct kvm *kvm, struct kvm_lapic *source,
> > kvm_for_each_vcpu(i, vcpu, kvm) {
> > if (kvm_apic_match_dest(vcpu, source, icrl & APIC_SHORT_MASK,
> > GET_APIC_DEST_FIELD(icrh),
> > - icrl & APIC_DEST_MASK))
> > - kvm_vcpu_wake_up(vcpu);
> > + icrl & APIC_DEST_MASK)) {
> > + vcpu->arch.apic->irr_pending = true;
> > + avic_kick_target_vcpu(vcpu);
> > + }
> > }
> > }
> >
> > @@ -671,9 +714,12 @@ void svm_load_eoi_exitmap(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap)
> >
> > int svm_deliver_avic_intr(struct kvm_vcpu *vcpu, int vec)
> > {
> > - if (!vcpu->arch.apicv_active)
> > - return -1;
> > -
> > + /*
> > + * Below, we have to handle anyway the case of AVIC being disabled
> > + * in the middle of this function, and there is hardly any overhead
> > + * if AVIC is disabled. So, we do not bother returning -1 and handle
> > + * the kick ourselves for disabled APICv.
>
> Hmm, my preference would be to keep the "return -1" even though apicv_active must
> be rechecked. That would help highlight that returning "failure" after this point
> is not an option as it would result in kvm_lapic_set_irr() being called twice.
I don't mind either - this will fix the tracepoint I recently added to report the
number of interrupts that were delivered by AVIC/APICv - with this patch,
all of them count as such.
I will also address all other feedback about the comments and send new version soon.
Thanks for the review!
Best regards,
Maxim Levitsky
>
> > + */
> > kvm_lapic_set_irr(vec, vcpu->arch.apic);
> >
> > /*
> > @@ -684,34 +730,7 @@ int svm_deliver_avic_intr(struct kvm_vcpu *vcpu, int vec)
> > * the doorbell if the vCPU is already running in the guest.
> > */
> > smp_mb__after_atomic();
> > -
> > - /*
> > - * Signal the doorbell to tell hardware to inject the IRQ if the vCPU
> > - * is in the guest. If the vCPU is not in the guest, hardware will
> > - * automatically process AVIC interrupts at VMRUN.
> > - */
> > - if (vcpu->mode == IN_GUEST_MODE) {
> > - int cpu = READ_ONCE(vcpu->cpu);
> > -
> > - /*
> > - * Note, the vCPU could get migrated to a different pCPU at any
> > - * point, which could result in signalling the wrong/previous
> > - * pCPU. But if that happens the vCPU is guaranteed to do a
> > - * VMRUN (after being migrated) and thus will process pending
> > - * interrupts, i.e. a doorbell is not needed (and the spurious
> > - * one is harmless).
> > - */
> > - if (cpu != get_cpu())
> > - wrmsrl(SVM_AVIC_DOORBELL, kvm_cpu_get_apicid(cpu));
> > - put_cpu();
> > - } else {
> > - /*
> > - * Wake the vCPU if it was blocking. KVM will then detect the
> > - * pending IRQ when checking if the vCPU has a wake event.
> > - */
> > - kvm_vcpu_wake_up(vcpu);
> > - }
> > -
> > + avic_kick_target_vcpu(vcpu);
> > return 0;
> > }
> >
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 85127b3e3690b..81a74d86ee5eb 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -9869,7 +9869,9 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> > * result in virtual interrupt delivery.
> > */
> > local_irq_disable();
> > - vcpu->mode = IN_GUEST_MODE;
> > +
> > + /* Store vcpu->apicv_active before vcpu->mode. */
> > + smp_store_release(&vcpu->mode, IN_GUEST_MODE);
> >
> > srcu_read_unlock(&vcpu->kvm->srcu, vcpu->srcu_idx);
> >
> > --
> > 2.26.3
> >
^ permalink raw reply
* [PATCH v3] ata: libata-scsi: simplify __ata_scsi_queuecmd()
From: Wenchao Hao @ 2022-01-06 0:13 UTC (permalink / raw)
To: Damien Le Moal, linux-ide, linux-kernel; +Cc: Zhiqiang Liu, Wenchao Hao
This is just a clean code. Since each branch of "if" state would check
scmd->cmd_len, so move the check of scmd->cmd_len out of "if" state to
simplify parameters check.
After the check of scmd->cmd_len is out of "if" state, we can remove
one redundant "if" state.
Remove a redundant variable "rc" by hand.
This patch do not change origin function logic.
Signed-off-by: Wenchao Hao <haowenchao@huawei.com>
---
drivers/ata/libata-scsi.c | 45 ++++++++++++++++++---------------------
1 file changed, 21 insertions(+), 24 deletions(-)
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index a16ef0030..ed8be585a 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -3958,42 +3958,39 @@ int __ata_scsi_queuecmd(struct scsi_cmnd *scmd, struct ata_device *dev)
{
u8 scsi_op = scmd->cmnd[0];
ata_xlat_func_t xlat_func;
- int rc = 0;
+
+ if (unlikely(!scmd->cmd_len))
+ goto bad_cdb_len;
if (dev->class == ATA_DEV_ATA || dev->class == ATA_DEV_ZAC) {
- if (unlikely(!scmd->cmd_len || scmd->cmd_len > dev->cdb_len))
+ if (unlikely(scmd->cmd_len > dev->cdb_len))
goto bad_cdb_len;
xlat_func = ata_get_xlat_func(dev, scsi_op);
- } else {
- if (unlikely(!scmd->cmd_len))
- goto bad_cdb_len;
+ } else if (likely((scsi_op != ATA_16) || !atapi_passthru16)) {
+ /* relay SCSI command to ATAPI device */
+ int len = COMMAND_SIZE(scsi_op);
- xlat_func = NULL;
- if (likely((scsi_op != ATA_16) || !atapi_passthru16)) {
- /* relay SCSI command to ATAPI device */
- int len = COMMAND_SIZE(scsi_op);
- if (unlikely(len > scmd->cmd_len ||
- len > dev->cdb_len ||
- scmd->cmd_len > ATAPI_CDB_LEN))
- goto bad_cdb_len;
+ if (unlikely(len > scmd->cmd_len ||
+ len > dev->cdb_len ||
+ scmd->cmd_len > ATAPI_CDB_LEN))
+ goto bad_cdb_len;
- xlat_func = atapi_xlat;
- } else {
- /* ATA_16 passthru, treat as an ATA command */
- if (unlikely(scmd->cmd_len > 16))
- goto bad_cdb_len;
+ xlat_func = atapi_xlat;
+ } else {
+ /* ATA_16 passthru, treat as an ATA command */
+ if (unlikely(scmd->cmd_len > 16))
+ goto bad_cdb_len;
- xlat_func = ata_get_xlat_func(dev, scsi_op);
- }
+ xlat_func = ata_get_xlat_func(dev, scsi_op);
}
if (xlat_func)
- rc = ata_scsi_translate(dev, scmd, xlat_func);
- else
- ata_scsi_simulate(dev, scmd);
+ return ata_scsi_translate(dev, scmd, xlat_func);
- return rc;
+ ata_scsi_simulate(dev, scmd);
+
+ return 0;
bad_cdb_len:
scmd->result = DID_ERROR << 16;
--
2.32.0
^ permalink raw reply related
* Re: [RFC 1/5] libvhost-user: Add vu_rem_mem_reg input validation
From: Stefan Hajnoczi @ 2022-01-05 11:00 UTC (permalink / raw)
To: Raphael Norwitz
Cc: marcandre.lureau@redhat.com, david@redhat.com,
qemu-devel@nongnu.org, raphael.s.norwitz@gmail.com,
mst@redhat.com
In-Reply-To: <20211215222939.24738-2-raphael.norwitz@nutanix.com>
[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]
On Wed, Dec 15, 2021 at 10:29:48PM +0000, Raphael Norwitz wrote:
> Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
> ---
> subprojects/libvhost-user/libvhost-user.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/subprojects/libvhost-user/libvhost-user.c b/subprojects/libvhost-user/libvhost-user.c
> index 787f4d2d4f..573212a83b 100644
> --- a/subprojects/libvhost-user/libvhost-user.c
> +++ b/subprojects/libvhost-user/libvhost-user.c
> @@ -801,6 +801,12 @@ vu_rem_mem_reg(VuDev *dev, VhostUserMsg *vmsg) {
> VuDevRegion shadow_regions[VHOST_USER_MAX_RAM_SLOTS] = {};
> VhostUserMemoryRegion m = vmsg->payload.memreg.region, *msg_region = &m;
>
> + if (vmsg->fd_num != 1 ||
> + vmsg->size != sizeof(vmsg->payload.memreg)) {
> + vu_panic(dev, "VHOST_USER_REM_MEM_REG received multiple regions");
> + return true;
Most vu_panic() callers return false to indicate that a reply does not
need to be sent. When the return value is true vu_dispatch() sends a
response, which we don't want.
Note that vu_dispatch() returns true (success) when the message handler
function returns false. The success/failure behavior should probably be
separated from the reply_requested behavior :(.
Anyway, returning false is probably appropriate here.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v1 4/4] ARM: dts: imx6dl: plym2m, prtvt7, victgo: make use of new resistive-adc-touch driver
From: Oleksij Rempel @ 2022-01-05 11:04 UTC (permalink / raw)
To: Shawn Guo
Cc: Mark Rutland, Rob Herring, Sascha Hauer, Thierry Reding,
Sam Ravnborg, David Airlie, Daniel Vetter, devicetree,
Fabio Estevam, linux-arm-kernel, linux-kernel, NXP Linux Team,
Pengutronix Kernel Team, David Jander, Robin van der Gracht,
dri-devel, Jonathan Cameron
In-Reply-To: <20211206010627.GK4216@dragon>
Hi Shawn,
sorry for the delay, I just came back to work.
On Mon, Dec 06, 2021 at 09:06:28AM +0800, Shawn Guo wrote:
> On Mon, Nov 22, 2021 at 01:43:10PM +0100, Oleksij Rempel wrote:
> > The tsc2046 is an ADC used as touchscreen controller. To share as mach
> > code as possible, we should use it as actual ADC + virtual tochscreen
> > controller.
> > With this patch we make use of the new kernel IIO and HID infrastructure.
> >
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
>
> One space is enough in subject "victgo: make".
done.
> > ---
> > arch/arm/boot/dts/imx6dl-plym2m.dts | 55 ++++++++++++++++++++---------
> > arch/arm/boot/dts/imx6dl-prtvt7.dts | 53 ++++++++++++++++++++-------
> > arch/arm/boot/dts/imx6dl-victgo.dts | 55 +++++++++++++++++++++--------
> > 3 files changed, 120 insertions(+), 43 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/imx6dl-plym2m.dts b/arch/arm/boot/dts/imx6dl-plym2m.dts
> > index 60fe5f14666e..e2afedae85cb 100644
> > --- a/arch/arm/boot/dts/imx6dl-plym2m.dts
> > +++ b/arch/arm/boot/dts/imx6dl-plym2m.dts
> > @@ -101,6 +101,17 @@ reg_12v0: regulator-12v0 {
> > regulator-min-microvolt = <12000000>;
> > regulator-max-microvolt = <12000000>;
> > };
> > +
> > + touchscreen {
> > + compatible = "resistive-adc-touch";
> > + io-channels = <&adc 1>, <&adc 3>, <&adc 4>, <&adc 5>;
> > + io-channel-names = "y", "z1", "z2", "x";
> > + touchscreen-min-pressure = <64687>;
> > + touchscreen-inverted-x;
> > + touchscreen-inverted-y;
> > + touchscreen-x-plate-ohms = <300>;
> > + touchscreen-y-plate-ohms = <800>;
> > + };
> > };
> >
> > &can1 {
> > @@ -129,26 +140,38 @@ &ecspi2 {
> > pinctrl-0 = <&pinctrl_ecspi2>;
> > status = "okay";
> >
> > - touchscreen@0 {
> > - compatible = "ti,tsc2046";
> > + adc: adc@0 {
>
> Isn't label name "adc" too generic?
I do not have strong opinion about this. Currently we have no
restrictions for the node names:
Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml
Documentation/devicetree/bindings/iio/adc/adc.yaml
I can name it touchscreen-adc@0 or something like this. What are your
preferences?
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH v1 4/4] ARM: dts: imx6dl: plym2m, prtvt7, victgo: make use of new resistive-adc-touch driver
From: Oleksij Rempel @ 2022-01-05 11:04 UTC (permalink / raw)
To: Shawn Guo
Cc: Mark Rutland, devicetree, Pengutronix Kernel Team,
Robin van der Gracht, David Airlie, Sascha Hauer, linux-kernel,
dri-devel, Jonathan Cameron, Rob Herring, Thierry Reding,
NXP Linux Team, David Jander, Sam Ravnborg, linux-arm-kernel
In-Reply-To: <20211206010627.GK4216@dragon>
Hi Shawn,
sorry for the delay, I just came back to work.
On Mon, Dec 06, 2021 at 09:06:28AM +0800, Shawn Guo wrote:
> On Mon, Nov 22, 2021 at 01:43:10PM +0100, Oleksij Rempel wrote:
> > The tsc2046 is an ADC used as touchscreen controller. To share as mach
> > code as possible, we should use it as actual ADC + virtual tochscreen
> > controller.
> > With this patch we make use of the new kernel IIO and HID infrastructure.
> >
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
>
> One space is enough in subject "victgo: make".
done.
> > ---
> > arch/arm/boot/dts/imx6dl-plym2m.dts | 55 ++++++++++++++++++++---------
> > arch/arm/boot/dts/imx6dl-prtvt7.dts | 53 ++++++++++++++++++++-------
> > arch/arm/boot/dts/imx6dl-victgo.dts | 55 +++++++++++++++++++++--------
> > 3 files changed, 120 insertions(+), 43 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/imx6dl-plym2m.dts b/arch/arm/boot/dts/imx6dl-plym2m.dts
> > index 60fe5f14666e..e2afedae85cb 100644
> > --- a/arch/arm/boot/dts/imx6dl-plym2m.dts
> > +++ b/arch/arm/boot/dts/imx6dl-plym2m.dts
> > @@ -101,6 +101,17 @@ reg_12v0: regulator-12v0 {
> > regulator-min-microvolt = <12000000>;
> > regulator-max-microvolt = <12000000>;
> > };
> > +
> > + touchscreen {
> > + compatible = "resistive-adc-touch";
> > + io-channels = <&adc 1>, <&adc 3>, <&adc 4>, <&adc 5>;
> > + io-channel-names = "y", "z1", "z2", "x";
> > + touchscreen-min-pressure = <64687>;
> > + touchscreen-inverted-x;
> > + touchscreen-inverted-y;
> > + touchscreen-x-plate-ohms = <300>;
> > + touchscreen-y-plate-ohms = <800>;
> > + };
> > };
> >
> > &can1 {
> > @@ -129,26 +140,38 @@ &ecspi2 {
> > pinctrl-0 = <&pinctrl_ecspi2>;
> > status = "okay";
> >
> > - touchscreen@0 {
> > - compatible = "ti,tsc2046";
> > + adc: adc@0 {
>
> Isn't label name "adc" too generic?
I do not have strong opinion about this. Currently we have no
restrictions for the node names:
Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml
Documentation/devicetree/bindings/iio/adc/adc.yaml
I can name it touchscreen-adc@0 or something like this. What are your
preferences?
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [Intel-gfx] [PATCH] drm/i915: stop including i915_irq.h from i915_drv.h
From: Tvrtko Ursulin @ 2022-01-05 11:05 UTC (permalink / raw)
To: Jani Nikula, intel-gfx
In-Reply-To: <20220105102131.988791-1-jani.nikula@intel.com>
On 05/01/2022 10:21, Jani Nikula wrote:
> Only include i915_irq.h where actually needed.
>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Regards,
Tvrtko
> ---
> drivers/gpu/drm/i915/display/intel_crtc.c | 1 +
> drivers/gpu/drm/i915/display/intel_display_trace.h | 1 +
> drivers/gpu/drm/i915/gt/intel_rps.c | 1 +
> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 1 +
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 1 +
> drivers/gpu/drm/i915/i915_drv.h | 1 -
> 6 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 16c3ca66d9f0..08ee3e17ee5c 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -12,6 +12,7 @@
> #include <drm/drm_plane_helper.h>
> #include <drm/drm_vblank_work.h>
>
> +#include "i915_irq.h"
> #include "i915_vgpu.h"
> #include "i9xx_plane.h"
> #include "icl_dsi.h"
> diff --git a/drivers/gpu/drm/i915/display/intel_display_trace.h b/drivers/gpu/drm/i915/display/intel_display_trace.h
> index 4043e1276383..f05f0f9b5103 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_trace.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_trace.h
> @@ -13,6 +13,7 @@
> #include <linux/tracepoint.h>
>
> #include "i915_drv.h"
> +#include "i915_irq.h"
> #include "intel_crtc.h"
> #include "intel_display_types.h"
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c
> index 54e7df788dbf..bd35e45d3aaa 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -6,6 +6,7 @@
> #include <drm/i915_drm.h>
>
> #include "i915_drv.h"
> +#include "i915_irq.h"
> #include "intel_breadcrumbs.h"
> #include "intel_gt.h"
> #include "intel_gt_clock_utils.h"
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> index 6e228343e8cb..0c52d1652e8b 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -12,6 +12,7 @@
> #include "intel_guc_ads.h"
> #include "intel_guc_submission.h"
> #include "i915_drv.h"
> +#include "i915_irq.h"
>
> /**
> * DOC: GuC
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> index ac0931f0374b..7b0b43e87244 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> @@ -7,6 +7,7 @@
>
> #include "gt/intel_gt.h"
> #include "i915_drv.h"
> +#include "i915_irq.h"
> #include "i915_memcpy.h"
> #include "intel_guc_log.h"
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index beeb42a14aae..3967748ba347 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -106,7 +106,6 @@
> #include "i915_scheduler.h"
> #include "gt/intel_timeline.h"
> #include "i915_vma.h"
> -#include "i915_irq.h"
>
>
> /* General customization:
>
^ permalink raw reply
* Re: [LTP] [PATCH] lib/tst_test.c: adjust the tst_kconfig_check position
From: Cyril Hrubis @ 2022-01-05 11:06 UTC (permalink / raw)
To: Yang Xu; +Cc: ltp
In-Reply-To: <1641374609-2143-1-git-send-email-xuyang2018.jy@fujitsu.com>
Hi!
Good catch.
Reviewed-by: Cyril Hrubis <chrubis@suse.cz>
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply
* [PATCH] i2c: at91: add compatible with microchip,sam9x60-i2c
From: Eugen Hristev @ 2022-01-05 11:05 UTC (permalink / raw)
To: hs, u-boot, michael; +Cc: Eugen Hristev
Add compatible and data platform struct for sam9x60 SoC.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
drivers/i2c/at91_i2c.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/i2c/at91_i2c.c b/drivers/i2c/at91_i2c.c
index 6b4c0e4804..e743d2a849 100644
--- a/drivers/i2c/at91_i2c.c
+++ b/drivers/i2c/at91_i2c.c
@@ -305,6 +305,11 @@ static const struct at91_i2c_pdata sama5d2_config = {
.clk_offset = 3,
};
+static const struct at91_i2c_pdata sam9x60_config = {
+ .clk_max_div = 7,
+ .clk_offset = 3,
+};
+
static const struct udevice_id at91_i2c_ids[] = {
{ .compatible = "atmel,at91rm9200-i2c", .data = (long)&at91rm9200_config },
{ .compatible = "atmel,at91sam9260-i2c", .data = (long)&at91sam9260_config },
@@ -314,6 +319,7 @@ static const struct udevice_id at91_i2c_ids[] = {
{ .compatible = "atmel,at91sam9x5-i2c", .data = (long)&at91sam9x5_config },
{ .compatible = "atmel,sama5d4-i2c", .data = (long)&sama5d4_config },
{ .compatible = "atmel,sama5d2-i2c", .data = (long)&sama5d2_config },
+{ .compatible = "microchip,sam9x60-i2c", .data = (long)&sam9x60_config },
{ }
};
--
2.25.1
^ permalink raw reply related
* Re: [RFC 2/5] libvhost-user: Add vu_add_mem_reg input validation
From: Stefan Hajnoczi @ 2022-01-05 11:02 UTC (permalink / raw)
To: Raphael Norwitz
Cc: marcandre.lureau@redhat.com, david@redhat.com,
qemu-devel@nongnu.org, raphael.s.norwitz@gmail.com,
mst@redhat.com
In-Reply-To: <20211215222939.24738-3-raphael.norwitz@nutanix.com>
[-- Attachment #1: Type: text/plain, Size: 901 bytes --]
On Wed, Dec 15, 2021 at 10:29:51PM +0000, Raphael Norwitz wrote:
> Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
> ---
> subprojects/libvhost-user/libvhost-user.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/subprojects/libvhost-user/libvhost-user.c b/subprojects/libvhost-user/libvhost-user.c
> index 573212a83b..80ef335254 100644
> --- a/subprojects/libvhost-user/libvhost-user.c
> +++ b/subprojects/libvhost-user/libvhost-user.c
> @@ -690,6 +690,12 @@ vu_add_mem_reg(VuDev *dev, VhostUserMsg *vmsg) {
> VuDevRegion *dev_region = &dev->regions[dev->nregions];
> void *mmap_addr;
>
> + if (vmsg->fd_num != 1 ||
> + vmsg->size != sizeof(vmsg->payload.memreg)) {
> + vu_panic(dev, "VHOST_USER_REM_MEM_REG received multiple regions");
> + return true;
return false - we don't want a reply to be sent.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v1 4/4] ARM: dts: imx6dl: plym2m, prtvt7, victgo: make use of new resistive-adc-touch driver
From: Oleksij Rempel @ 2022-01-05 11:04 UTC (permalink / raw)
To: Shawn Guo
Cc: Mark Rutland, Rob Herring, Sascha Hauer, Thierry Reding,
Sam Ravnborg, David Airlie, Daniel Vetter, devicetree,
Fabio Estevam, linux-arm-kernel, linux-kernel, NXP Linux Team,
Pengutronix Kernel Team, David Jander, Robin van der Gracht,
dri-devel, Jonathan Cameron
In-Reply-To: <20211206010627.GK4216@dragon>
Hi Shawn,
sorry for the delay, I just came back to work.
On Mon, Dec 06, 2021 at 09:06:28AM +0800, Shawn Guo wrote:
> On Mon, Nov 22, 2021 at 01:43:10PM +0100, Oleksij Rempel wrote:
> > The tsc2046 is an ADC used as touchscreen controller. To share as mach
> > code as possible, we should use it as actual ADC + virtual tochscreen
> > controller.
> > With this patch we make use of the new kernel IIO and HID infrastructure.
> >
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
>
> One space is enough in subject "victgo: make".
done.
> > ---
> > arch/arm/boot/dts/imx6dl-plym2m.dts | 55 ++++++++++++++++++++---------
> > arch/arm/boot/dts/imx6dl-prtvt7.dts | 53 ++++++++++++++++++++-------
> > arch/arm/boot/dts/imx6dl-victgo.dts | 55 +++++++++++++++++++++--------
> > 3 files changed, 120 insertions(+), 43 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/imx6dl-plym2m.dts b/arch/arm/boot/dts/imx6dl-plym2m.dts
> > index 60fe5f14666e..e2afedae85cb 100644
> > --- a/arch/arm/boot/dts/imx6dl-plym2m.dts
> > +++ b/arch/arm/boot/dts/imx6dl-plym2m.dts
> > @@ -101,6 +101,17 @@ reg_12v0: regulator-12v0 {
> > regulator-min-microvolt = <12000000>;
> > regulator-max-microvolt = <12000000>;
> > };
> > +
> > + touchscreen {
> > + compatible = "resistive-adc-touch";
> > + io-channels = <&adc 1>, <&adc 3>, <&adc 4>, <&adc 5>;
> > + io-channel-names = "y", "z1", "z2", "x";
> > + touchscreen-min-pressure = <64687>;
> > + touchscreen-inverted-x;
> > + touchscreen-inverted-y;
> > + touchscreen-x-plate-ohms = <300>;
> > + touchscreen-y-plate-ohms = <800>;
> > + };
> > };
> >
> > &can1 {
> > @@ -129,26 +140,38 @@ &ecspi2 {
> > pinctrl-0 = <&pinctrl_ecspi2>;
> > status = "okay";
> >
> > - touchscreen@0 {
> > - compatible = "ti,tsc2046";
> > + adc: adc@0 {
>
> Isn't label name "adc" too generic?
I do not have strong opinion about this. Currently we have no
restrictions for the node names:
Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml
Documentation/devicetree/bindings/iio/adc/adc.yaml
I can name it touchscreen-adc@0 or something like this. What are your
preferences?
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] platform/x86: Add Asus TF103C dock driver
From: Hans de Goede @ 2022-01-05 11:06 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Mark Gross, Andy Shevchenko, platform-driver-x86,
Michał Mirosław, Ion Agorria, Svyatoslav Ryhel
In-Reply-To: <YdRokPBoYYnF+D3D@smile.fi.intel.com>
Hi,
Thank you for the review.
On 1/4/22 16:32, Andy Shevchenko wrote:
> On Sun, Dec 26, 2021 at 03:18:49PM +0100, Hans de Goede wrote:
>> Add a driver for the keyboard, touchpad and USB port of
>> the keyboard dock for the Asus TF103C 2-in-1 tablet.
>>
>> This keyboard dock has its own I2C attached embedded controller
>> and the keyboard and touchpad are also connected over I2C,
>> instead of using the usual USB connection. This means that the
>> keyboard dock requires this special driver to function.
>
> ...
>
>> +MODULE_PARM_DESC(fnlock,
>> + "By default the kbd toprow sends multimedia key presses. AltGr "
>> + "can be pressed to change this to F1-F12. Set this to 1 to "
>> + "change the default. Press AltGr + Esc to toggle at runtime.");
>
> I would still use long line instead of splitting.
Well the normal grepping for log messages argument does not really apply
here and making this one long line would be pretty unreadable IMHO, so I'm
going to keep this as is.
>
> ...
>
>> +/* Byte 0 is the length of the rest of the packet */
>> +static const u8 tf103c_dock_enable_cmd[9] = { 8, 0x20, 0, 0, 0, 0, 0x20, 0, 0 };
>> +static const u8 tf103c_dock_usb_enable_cmd[9] = { 8, 0, 0, 0, 0, 0, 0, 0x40, 0 };
>> +static const u8 tf103c_dock_suspend_cmd[9] = { 8, 0, 0x20, 0, 0, 0x22, 0, 0, 0 };
>
> This seems to me rather
>
> struct {
> u8 cmd;
> DECLARE_BITMAP(payload, 64);
> };
>
> And those 2s and 4s are actually some bits in payload with some meaning.
>
> Would it be the case?
Something like that yes, there are some hints that this is a bitfield in
the Android driver code, but then in other places it seems to be more of
a command structure then just individual bits having a meaning.
All in all we really don't know, so I'm going to keep this as just
an opaque array of bytes, because that is really what it is / what we know
about it.
>
> ...
>
>> +/*** keyboard related code ***/
>
> Not sure why you have all those fancy tri-stars comments. Probably it's
> feliz año nuevo style -)
hehe, the driver is somewhat large, I've tried to group various
sub bits, like keyboard handling, touchpad handling, etc. together.
These are dividers for the different groups, which is why I gave them
a different style then normal comments.
>
> ...
>
>> + ret = i2c_transfer(client->adapter, msgs, 2);
>> + if (ret != 2) {
>
> 2 --> ARRAY_SIZE() ?
Fixed in my review-hans branch (where this already landed).
>
>> + dev_err(dev, "error %d reading kbd data\n", ret);
>> + return -EIO;
>> + }
>
> ...
>
>> + buf[0] = TF103C_DOCK_KBD_CMD_REG & 0xff;
>> + buf[1] = TF103C_DOCK_KBD_CMD_REG >> 8;
>> + buf[2] = cmd & 0xff;
>> + buf[3] = cmd >> 8;
>
> Seems to me like put_unaligned_le16() in both cases,
Fixed in my review-hans branch.
>
> ...
>
>> + ret = i2c_master_send(dock->kbd_client, buf, 4);
>> + if (ret != 4)
>
> sizeof() / ARRAY_SIZE() ?
Fixed in my review-hans branch.
>
>> + dev_err(dev, "error %d writing kbd cmd\n", ret);
>
> ...
>
>> +static const struct acpi_device_id tf103c_dock_acpi_match[] = {
>> + {"NPCE69A"},
>
>> + { },
>
> No comma is needed.
Fixed in my review-hans branch.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH 13/17] PCI: aardvark: Fix support for PME requester on emulated bridge
From: Marek Behún @ 2022-01-05 11:07 UTC (permalink / raw)
To: Lorenzo Pieralisi, Marc Zyngier; +Cc: linux-pci, pali
In-Reply-To: <20211208061851.31867-14-kabel@kernel.org>
On Wed, 8 Dec 2021 07:18:47 +0100
Marek Behún <kabel@kernel.org> wrote:
> + dev_err_ratelimited(&pcie->pdev->dev, "unhandled ERR IRQ\n");
This should say "unhandled PME IRQ\n". Ah.
^ permalink raw reply
* Re: [RFC 3/5] libvhost-user: Simplify VHOST_USER_REM_MEM_REG
From: Stefan Hajnoczi @ 2022-01-05 11:04 UTC (permalink / raw)
To: Raphael Norwitz
Cc: marcandre.lureau@redhat.com, david@redhat.com,
qemu-devel@nongnu.org, raphael.s.norwitz@gmail.com,
mst@redhat.com
In-Reply-To: <20211215222939.24738-4-raphael.norwitz@nutanix.com>
[-- Attachment #1: Type: text/plain, Size: 594 bytes --]
On Wed, Dec 15, 2021 at 10:29:52PM +0000, Raphael Norwitz wrote:
> From: David Hildenbrand <david@redhat.com>
>
> Let's avoid having to manually copy all elements. Copy only the ones
> necessary to close the hole and perform the operation in-place without
> a second array.
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
> ---
> subprojects/libvhost-user/libvhost-user.c | 30 +++++++++++------------
> 1 file changed, 14 insertions(+), 16 deletions(-)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC 4/5] libvhost-user: prevent over-running max RAM slots
From: Stefan Hajnoczi @ 2022-01-05 11:06 UTC (permalink / raw)
To: Raphael Norwitz
Cc: marcandre.lureau@redhat.com, david@redhat.com,
qemu-devel@nongnu.org, raphael.s.norwitz@gmail.com,
mst@redhat.com
In-Reply-To: <20211215222939.24738-5-raphael.norwitz@nutanix.com>
[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]
On Wed, Dec 15, 2021 at 10:29:54PM +0000, Raphael Norwitz wrote:
> When VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS support was added to
> libvhost-user, no guardrails were added to protect against QEMU
> attempting to hot-add too many RAM slots to a VM with a libvhost-user
> based backed attached.
>
> This change adds the missing error handling by introducing a check on
> the number of RAM slots the device has available before proceeding to
> process the VHOST_USER_ADD_MEM_REG message.
>
> Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
> Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
> ---
> subprojects/libvhost-user/libvhost-user.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/subprojects/libvhost-user/libvhost-user.c b/subprojects/libvhost-user/libvhost-user.c
> index 714cc7e08b..74a9980194 100644
> --- a/subprojects/libvhost-user/libvhost-user.c
> +++ b/subprojects/libvhost-user/libvhost-user.c
> @@ -690,6 +690,11 @@ vu_add_mem_reg(VuDev *dev, VhostUserMsg *vmsg) {
> VuDevRegion *dev_region = &dev->regions[dev->nregions];
> void *mmap_addr;
>
> + if (dev->nregions == VHOST_USER_MAX_RAM_SLOTS) {
> + vu_panic(dev, "No free ram slots available");
> + return true;
return false
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 7/7] ARM: implement support for vmap'ed stacks
From: Jon Hunter @ 2022-01-05 11:08 UTC (permalink / raw)
To: Geert Uytterhoeven, Ard Biesheuvel
Cc: Marek Szyprowski, Linux ARM, Russell King, Nicolas Pitre,
Arnd Bergmann, Kees Cook, Keith Packard, Linus Walleij,
Nick Desaulniers, Tony Lindgren, Krzysztof Kozlowski,
Linux Samsung SOC, Linux-Renesas, linux-tegra@vger.kernel.org
In-Reply-To: <CAMuHMdWNuCVeFiDrhnFmX0F1jxz8Fs4eFx55ojJF3d2ro-udrA@mail.gmail.com>
Hi Ard,
On 28/12/2021 14:39, Geert Uytterhoeven wrote:
...
>> As i don't have access to this hardware, I am going to have to rely on
>> someone who does to debug this further. The only alternative is
>> marking CONFIG_VMAP_STACK broken on MACH_EXYNOS but that would be
>> unfortunate.
>
> Wish I had seen this thread before...
>
> I've just bisected a resume after s2ram failure on R-Car Gen2 to the same
> commit a1c510d0adc604bb ("ARM: implement support for vmap'ed stacks")
> in arm/for-next.
>
> Expected output:
>
> PM: suspend entry (deep)
> Filesystems sync: 0.000 seconds
> Freezing user space processes ... (elapsed 0.010 seconds) done.
> OOM killer disabled.
> Freezing remaining freezable tasks ... (elapsed 0.009 seconds) done.
> Disabling non-boot CPUs ...
>
> [system suspended, this is also where it hangs on failure]
>
> Enabling non-boot CPUs ...
> CPU1 is up
> sh-eth ee700000.ethernet eth0: Link is Down
> Micrel KSZ8041RNLI ee700000.ethernet-ffffffff:01: attached PHY
> driver (mii_bus:phy_addr=ee700000.ethernet-ffffffff:01, irq=193)
> OOM killer enabled.
> Restarting tasks ... done.
> PM: suspend exit
>
> Both wake-on-LAN and wake-up by gpio-keys fail.
> Nothing interesting in the kernel log, cfr. above.
>
> Disabling CONFIG_VMAP_STACK fixes the issue for me.
>
> Just like arch/arm/mach-exynos/ (and others), arch/arm/mach-shmobile/
> has several *.S files related to secondary CPU bringup.
This is also breaking suspend on our 32-bit Tegra platforms. Reverting
this change on top of -next fixes the problem.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v4 7/7] ARM: implement support for vmap'ed stacks
From: Jon Hunter @ 2022-01-05 11:08 UTC (permalink / raw)
To: Geert Uytterhoeven, Ard Biesheuvel
Cc: Marek Szyprowski, Linux ARM, Russell King, Nicolas Pitre,
Arnd Bergmann, Kees Cook, Keith Packard, Linus Walleij,
Nick Desaulniers, Tony Lindgren, Krzysztof Kozlowski,
Linux Samsung SOC, Linux-Renesas, linux-tegra@vger.kernel.org
In-Reply-To: <CAMuHMdWNuCVeFiDrhnFmX0F1jxz8Fs4eFx55ojJF3d2ro-udrA@mail.gmail.com>
Hi Ard,
On 28/12/2021 14:39, Geert Uytterhoeven wrote:
...
>> As i don't have access to this hardware, I am going to have to rely on
>> someone who does to debug this further. The only alternative is
>> marking CONFIG_VMAP_STACK broken on MACH_EXYNOS but that would be
>> unfortunate.
>
> Wish I had seen this thread before...
>
> I've just bisected a resume after s2ram failure on R-Car Gen2 to the same
> commit a1c510d0adc604bb ("ARM: implement support for vmap'ed stacks")
> in arm/for-next.
>
> Expected output:
>
> PM: suspend entry (deep)
> Filesystems sync: 0.000 seconds
> Freezing user space processes ... (elapsed 0.010 seconds) done.
> OOM killer disabled.
> Freezing remaining freezable tasks ... (elapsed 0.009 seconds) done.
> Disabling non-boot CPUs ...
>
> [system suspended, this is also where it hangs on failure]
>
> Enabling non-boot CPUs ...
> CPU1 is up
> sh-eth ee700000.ethernet eth0: Link is Down
> Micrel KSZ8041RNLI ee700000.ethernet-ffffffff:01: attached PHY
> driver (mii_bus:phy_addr=ee700000.ethernet-ffffffff:01, irq=193)
> OOM killer enabled.
> Restarting tasks ... done.
> PM: suspend exit
>
> Both wake-on-LAN and wake-up by gpio-keys fail.
> Nothing interesting in the kernel log, cfr. above.
>
> Disabling CONFIG_VMAP_STACK fixes the issue for me.
>
> Just like arch/arm/mach-exynos/ (and others), arch/arm/mach-shmobile/
> has several *.S files related to secondary CPU bringup.
This is also breaking suspend on our 32-bit Tegra platforms. Reverting
this change on top of -next fixes the problem.
Cheers
Jon
--
nvpublic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] media: atmel: atmel-isc: Fix PM disable depth imbalance in atmel_isc_probe
From: Miaoqian Lin @ 2022-01-05 11:10 UTC (permalink / raw)
Cc: linmq006, Eugen Hristev, Mauro Carvalho Chehab, Nicolas Ferre,
Alexandre Belloni, Ludovic Desroches, Hans Verkuil, linux-media,
linux-arm-kernel, linux-kernel
The pm_runtime_enable will increase power disable depth.
If the probe fails, we should use pm_runtime_disable() to balance
pm_runtime_enable().
Fixes: 0a0e265 ("media: atmel: atmel-isc: split driver into driver base and isc")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
---
drivers/media/platform/atmel/atmel-sama5d2-isc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 1b2063cce0f7..88a81c3ada90 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -559,6 +559,9 @@ static int atmel_isc_probe(struct platform_device *pdev)
cleanup_subdev:
isc_subdev_cleanup(isc);
+disable_pm_runtime:
+ pm_runtime_disable(dev);
+
unregister_v4l2_device:
v4l2_device_unregister(&isc->v4l2_dev);
--
2.17.1
^ permalink raw reply related
* Re: [ERROR: Nothing RPROVIDES 'u-boot-default-env']
From: Nikhil V @ 2022-01-05 11:10 UTC (permalink / raw)
To: akartashev; +Cc: openbmc
In-Reply-To: <17e20148a9c.10fd4f6105879.8717643372259739590@zohocorp.com>
[-- Attachment #1: Type: text/plain, Size: 6901 bytes --]
hi,
What are your expectations and final goal?
Trying to implement openbmc on SAMA5D27 development board and to use secure boot feature provided by microchip. To make openbmc more secure.
Looking at boot sequence of SAMA5D27
(https://microchipdeveloper.com/32mpu:boot-sama5d2-series and http://ww1.microchip.com/downloads/en/AppNotes/DS00002748A.pdf)
• ROM code (first stage loader)
• AT91bootstrap bootloader (second stage loader)
• U-Boot bootloader (third stage loader)
In Normal Situation for eg. if we implement openbmc in beaglebone black bootprocess seen by openbmc
• ROM code (first stage loader)
• U-Boot bootloader (second stage loader)
Is additional layer of AT91bootstrap causing problem to openbmc to give "ERROR" during bitbake?
Thanks & Regards,
Nikhil Muley
---- On Mon, 03 Jan 2022 18:45:24 +0530 Nikhil V <nikhil.vu@zohocorp.com> wrote ----
Hello Andrei Kartashev,
Thanks for your patience and support.
As suggested by you to try with normal yocto build and then go for OpenBMC.
I have a success with yocto image for SAMA5D27 development board and tested and verified using steps described in following link
( https://www.linux4sam.org/bin/view/Linux4SAM/Sama5d27Som1EKMainPage )
But i got error when i do same for openbmc,
As i am new to openbmc and may be i am wrong with my interpretation
I have the following Interpretation towards problem.
If you look into meta/recipe-bsp/u-boot/libubootenv_0.3.1.bb
It describe that it "It provides hardware-independent replacement for fw_printenv/setenv utilities provided by U-Boot"
If you look into meta-atmel/recipe-bsp
There is nothing indicating fw_printenv/setenv at u-boot-at91_2020.01.bb recipe.
Correct me if I am wrong.
Thanks & Regards,
Nikhil Muley
---- On Mon, 03 Jan 2022 18:00:56 +0530 Andrei Kartashev <mailto:a.kartashev@yadro.com> wrote ----
Well, as I say, they don't use u-boot.inc an they don't implement u-
boot-default-env. I can't give you an universal hint on how to solve
this, but I advice you to build upstream Yocto for your platform first
(I mean, generic yocto, instead of OpenBMC). Once you succeeded with
upstream Yocto, integrating into OpenBMC would be less painful.
What you trying to do is not a typical usecase for OpenBMC, generally
we don't do like this. What are your expectations and final goal?
On Mon, 2022-01-03 at 17:06 +0530, Nikhil V wrote:
> Hello kartashev,
> Thanks for your quick response, I will provide
> some background on what i am trying to achieve.
> I am using openbmc, downloaded from following
> location, steps are as follow,
>
> 1) git clone
> https://github.com/openbmc/openbmc.git -b dunfell
> 2) git clone
> git://github.com/linux4sam/meta-atmel.git -b dunfell
> 3) . openbmc-env build-sama5d27
> 4) then add following layers
> bitbake-layers add-layer ../meta-atmel
> ../meta-security ../meta-openembedded/meta-perl ../meta-
> openembedded/meta-initramfs
> 5) Edit in local.conf
> MACHINE="sama5d27-som1-ek-sd"
> 6) bitbake obmc-phosphor-image
>
> "Since there is no such platform as "at91" in OpenBMC, we don't know
> what recipe do you use for u-boot."
> Here I am using meta-atmel layer provided by microchip. It has its
> own u-boot under meta-atmel/recipe-bsp.
> you will find it once you downloaded it from step 2.
>
> when i do bitbake obmc-phosphor-image i am getting error. ERROR:
> Nothing RPROVIDES 'u-boot-default-env'
>
> hope i have described my problem correctly.
>
> For any query feel free to contact.
>
> Thanks & Regards,
> Nikhil Muley
>
>
> ---- On Mon, 03 Jan 2022 16:40:09 +0530 Andrei Kartashev
> <mailto:a.kartashev@yadro.com> wrote ----
>
> > Hello,
> >
> > It's hard to say what's wrong without knowing of what are you
> > exactly
> > doing. Since there is no such platform as "at91" in OpenBMC, we
> > don't
> > know what recipe do you use for u-boot.
> > Generally, u-boot recipe should include u-boot.inc:
> >
> > > require recipes-bsp/u-boot/u-boot.inc
> >
> > This include file provide u-boot-default-env recipe
> > https://github.com/openbmc/openbmc/blob/master/poky/meta/recipes-bsp/u-boot/u-boot.inc#L215
> >
> > On Mon, 2022-01-03 at 15:34 +0530, Nikhil V wrote:
> > > Hi,
> > > I am trying to build image for openbmc on SAMA5D27-som1-ek1
> > > development board made by microchip(atmel). SAMA5D27 board has
> > > yocto
> > > support.
> > > I have added meta-atmel layer to openbmc, while
> > > building/compiling
> > > using " bitbake obmc-phosphor-image ", I am facing following
> > > error,
> > >
> > > [ERROR: Nothing RPROVIDES 'u-boot-default-env']
> > >
> > > I have tried by updating with following content but didnt
> > > get any
> > > result.
> > > PREFERRED_PROVIDER_u-boot = "u-boot-at91"
> > > PREFERRED_PROVIDER_virtual/bootloader = "u-boot-
> > > at91"
> > >
> > > Can you help me to find a solution.
> > >
> > >
> > > Thanks & Regards,
> > > Nikhil Muley
> > >
> > >
> > >
> >
--
Best regards,
Andrei Kartashev
[-- Attachment #2: Type: text/html, Size: 12976 bytes --]
^ permalink raw reply
* [PATCH] media: atmel: atmel-isc: Fix PM disable depth imbalance in atmel_isc_probe
From: Miaoqian Lin @ 2022-01-05 11:10 UTC (permalink / raw)
Cc: linmq006, Alexandre Belloni, linux-kernel, Ludovic Desroches,
Hans Verkuil, Eugen Hristev, Mauro Carvalho Chehab,
linux-arm-kernel, linux-media
The pm_runtime_enable will increase power disable depth.
If the probe fails, we should use pm_runtime_disable() to balance
pm_runtime_enable().
Fixes: 0a0e265 ("media: atmel: atmel-isc: split driver into driver base and isc")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
---
drivers/media/platform/atmel/atmel-sama5d2-isc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 1b2063cce0f7..88a81c3ada90 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -559,6 +559,9 @@ static int atmel_isc_probe(struct platform_device *pdev)
cleanup_subdev:
isc_subdev_cleanup(isc);
+disable_pm_runtime:
+ pm_runtime_disable(dev);
+
unregister_v4l2_device:
v4l2_device_unregister(&isc->v4l2_dev);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v6 0/9] Multigenerational LRU Framework
From: Borislav Petkov @ 2022-01-05 11:12 UTC (permalink / raw)
To: Yu Zhao
Cc: SeongJae Park, Andrew Morton, Linus Torvalds, Andi Kleen,
Catalin Marinas, Dave Hansen, Hillf Danton, Jens Axboe,
Jesse Barnes, Johannes Weiner, Jonathan Corbet, Matthew Wilcox,
Mel Gorman, Michael Larabel, Michal Hocko, Rik van Riel,
Vlastimil Babka, Will Deacon, Ying Huang, linux-arm-kernel,
linux-doc, linux-kernel, linux-mm, page-reclaim, x86
In-Reply-To: <YdV4k1+zEbtzmUkK@google.com>
On Wed, Jan 05, 2022 at 03:53:07AM -0700, Yu Zhao wrote:
> Look, I'm open to your suggestion. I probably should have been nicer.
> So I'm sorry. I just don't appreciate alternative facts.
Yes, you should've been *much* nicer. I'm reading lkml for pretty much
20 years now and you just made my eyebrows go up - something which
pretty much never happens these days.
So you need to check yourself before replying. Looking at git history,
you're not a newbie so you've probably picked up - at least from the
sidelines - all those code of conduct discussions. And I'm not going to
point you to it - I'm sure you can find it yourself and peruse it at
your own convenience.
Long story short: we all try to be civil to each other now, even if it
is hard sometimes.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH v4 7/7] ARM: implement support for vmap'ed stacks
From: Ard Biesheuvel @ 2022-01-05 11:12 UTC (permalink / raw)
To: Jon Hunter
Cc: Geert Uytterhoeven, Marek Szyprowski, Linux ARM, Russell King,
Nicolas Pitre, Arnd Bergmann, Kees Cook, Keith Packard,
Linus Walleij, Nick Desaulniers, Tony Lindgren,
Krzysztof Kozlowski, Linux Samsung SOC, Linux-Renesas,
linux-tegra@vger.kernel.org
In-Reply-To: <bbb0c788-bd83-833c-9445-87cff525f728@nvidia.com>
On Wed, 5 Jan 2022 at 12:08, Jon Hunter <jonathanh@nvidia.com> wrote:
>
> Hi Ard,
>
> On 28/12/2021 14:39, Geert Uytterhoeven wrote:
>
> ...
>
> >> As i don't have access to this hardware, I am going to have to rely on
> >> someone who does to debug this further. The only alternative is
> >> marking CONFIG_VMAP_STACK broken on MACH_EXYNOS but that would be
> >> unfortunate.
> >
> > Wish I had seen this thread before...
> >
> > I've just bisected a resume after s2ram failure on R-Car Gen2 to the same
> > commit a1c510d0adc604bb ("ARM: implement support for vmap'ed stacks")
> > in arm/for-next.
> >
> > Expected output:
> >
> > PM: suspend entry (deep)
> > Filesystems sync: 0.000 seconds
> > Freezing user space processes ... (elapsed 0.010 seconds) done.
> > OOM killer disabled.
> > Freezing remaining freezable tasks ... (elapsed 0.009 seconds) done.
> > Disabling non-boot CPUs ...
> >
> > [system suspended, this is also where it hangs on failure]
> >
> > Enabling non-boot CPUs ...
> > CPU1 is up
> > sh-eth ee700000.ethernet eth0: Link is Down
> > Micrel KSZ8041RNLI ee700000.ethernet-ffffffff:01: attached PHY
> > driver (mii_bus:phy_addr=ee700000.ethernet-ffffffff:01, irq=193)
> > OOM killer enabled.
> > Restarting tasks ... done.
> > PM: suspend exit
> >
> > Both wake-on-LAN and wake-up by gpio-keys fail.
> > Nothing interesting in the kernel log, cfr. above.
> >
> > Disabling CONFIG_VMAP_STACK fixes the issue for me.
> >
> > Just like arch/arm/mach-exynos/ (and others), arch/arm/mach-shmobile/
> > has several *.S files related to secondary CPU bringup.
>
>
> This is also breaking suspend on our 32-bit Tegra platforms. Reverting
> this change on top of -next fixes the problem.
>
Thanks for the report.
It would be helpful if you could provide some more context:
- does it happen on a LPAE build too?
- does it only happen on SMP capable systems?
- does it reproduce on such systems when using only a single CPU?
(i.e., pass 'nosmp' on the kernel command line)
- when passing 'no_console_suspend' on the kernel command line, are
any useful diagnostics produced?
- is there any way you could tell whether the crash/hang (assuming
that is what you are observing) occurs on the suspend path or on
resume?
- any other observations that could narrow this down?
Thanks,
Ard.
^ permalink raw reply
* Re: [PATCH v4 7/7] ARM: implement support for vmap'ed stacks
From: Ard Biesheuvel @ 2022-01-05 11:12 UTC (permalink / raw)
To: Jon Hunter
Cc: Geert Uytterhoeven, Marek Szyprowski, Linux ARM, Russell King,
Nicolas Pitre, Arnd Bergmann, Kees Cook, Keith Packard,
Linus Walleij, Nick Desaulniers, Tony Lindgren,
Krzysztof Kozlowski, Linux Samsung SOC, Linux-Renesas,
linux-tegra@vger.kernel.org
In-Reply-To: <bbb0c788-bd83-833c-9445-87cff525f728@nvidia.com>
On Wed, 5 Jan 2022 at 12:08, Jon Hunter <jonathanh@nvidia.com> wrote:
>
> Hi Ard,
>
> On 28/12/2021 14:39, Geert Uytterhoeven wrote:
>
> ...
>
> >> As i don't have access to this hardware, I am going to have to rely on
> >> someone who does to debug this further. The only alternative is
> >> marking CONFIG_VMAP_STACK broken on MACH_EXYNOS but that would be
> >> unfortunate.
> >
> > Wish I had seen this thread before...
> >
> > I've just bisected a resume after s2ram failure on R-Car Gen2 to the same
> > commit a1c510d0adc604bb ("ARM: implement support for vmap'ed stacks")
> > in arm/for-next.
> >
> > Expected output:
> >
> > PM: suspend entry (deep)
> > Filesystems sync: 0.000 seconds
> > Freezing user space processes ... (elapsed 0.010 seconds) done.
> > OOM killer disabled.
> > Freezing remaining freezable tasks ... (elapsed 0.009 seconds) done.
> > Disabling non-boot CPUs ...
> >
> > [system suspended, this is also where it hangs on failure]
> >
> > Enabling non-boot CPUs ...
> > CPU1 is up
> > sh-eth ee700000.ethernet eth0: Link is Down
> > Micrel KSZ8041RNLI ee700000.ethernet-ffffffff:01: attached PHY
> > driver (mii_bus:phy_addr=ee700000.ethernet-ffffffff:01, irq=193)
> > OOM killer enabled.
> > Restarting tasks ... done.
> > PM: suspend exit
> >
> > Both wake-on-LAN and wake-up by gpio-keys fail.
> > Nothing interesting in the kernel log, cfr. above.
> >
> > Disabling CONFIG_VMAP_STACK fixes the issue for me.
> >
> > Just like arch/arm/mach-exynos/ (and others), arch/arm/mach-shmobile/
> > has several *.S files related to secondary CPU bringup.
>
>
> This is also breaking suspend on our 32-bit Tegra platforms. Reverting
> this change on top of -next fixes the problem.
>
Thanks for the report.
It would be helpful if you could provide some more context:
- does it happen on a LPAE build too?
- does it only happen on SMP capable systems?
- does it reproduce on such systems when using only a single CPU?
(i.e., pass 'nosmp' on the kernel command line)
- when passing 'no_console_suspend' on the kernel command line, are
any useful diagnostics produced?
- is there any way you could tell whether the crash/hang (assuming
that is what you are observing) occurs on the suspend path or on
resume?
- any other observations that could narrow this down?
Thanks,
Ard.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 0/9] Multigenerational LRU Framework
From: Borislav Petkov @ 2022-01-05 11:12 UTC (permalink / raw)
To: Yu Zhao
Cc: SeongJae Park, Andrew Morton, Linus Torvalds, Andi Kleen,
Catalin Marinas, Dave Hansen, Hillf Danton, Jens Axboe,
Jesse Barnes, Johannes Weiner, Jonathan Corbet, Matthew Wilcox,
Mel Gorman, Michael Larabel, Michal Hocko, Rik van Riel,
Vlastimil Babka, Will Deacon, Ying Huang, linux-arm-kernel,
linux-doc, linux-kernel, linux-mm, page-reclaim, x86
In-Reply-To: <YdV4k1+zEbtzmUkK@google.com>
On Wed, Jan 05, 2022 at 03:53:07AM -0700, Yu Zhao wrote:
> Look, I'm open to your suggestion. I probably should have been nicer.
> So I'm sorry. I just don't appreciate alternative facts.
Yes, you should've been *much* nicer. I'm reading lkml for pretty much
20 years now and you just made my eyebrows go up - something which
pretty much never happens these days.
So you need to check yourself before replying. Looking at git history,
you're not a newbie so you've probably picked up - at least from the
sidelines - all those code of conduct discussions. And I'm not going to
point you to it - I'm sure you can find it yourself and peruse it at
your own convenience.
Long story short: we all try to be civil to each other now, even if it
is hard sometimes.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.