"Question about...". What is the question?
Also, given that your question concerns what happens when you write to
/sys/bus/pci/..., perhaps you should consider mailing it to some PCI
maintainers as well as to the USB maintainers.
Perhaps the reset was not meant to be used the way you are doing it.
A more conservative approach would be to unbind xhci-hcd from the
device before doing the reset and then rebind it afterward.
Alan Stern
_read_bool(port->dev->of_node, "auto-flow-control") ||
> + (termios->c_cflag & CRTSCTS))
> + escr |= MLB_USIO_ESCR_FLWEN;
That's just broken. The termios bits are the definitive things for the
port, and in addition even if they are forced you need to correct the
termios data.
You might want to control flow control *at boot* with an OF property but
doing it post boot is just busted.
Alan
Add the two ltc2497 devices that are on the SoCFPGA Arria10
Socdk board at addresses 0x14 and 0x16.
Signed-off-by: Alan Tull
---
arch/arm/boot/dts/socfpga_arria10_socdk.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi
b
Enable the LTC2497 driver to support the two LTC2497's that are on
the SoCFPGA Arria10 Devkit.
Signed-off-by: Alan Tull
---
arch/arm/configs/socfpga_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/socfpga_defconfig
b/arch/arm/configs/socfpga_defconfig
On Wed, 24 Apr 2019, Paul E. McKenney wrote:
> On Mon, Apr 22, 2019 at 12:17:45PM -0400, Alan Stern wrote:
> > This patch makes some slight alterations to linux-kernel.cat in
> > preparation for adding support for data-race detection to the
> > Linux-Kernel Memory Mo
On Tue, 23 Apr 2019, Jesse Hathaway wrote:
> On Tue, Apr 16, 2019 at 10:00 AM Alan Stern wrote:
> > Whatever the source of the problem, I don't think you're going to find
> > it by looking at the USB code. Perhaps the early initialization of the
> > functions th
This patch adds definitions for marked and plain accesses to the
Linux-Kernel Memory Model. It also modifies the definitions of the
existing parts of the model (including the cumul-fence, prop, hb, pb,
and rb relations) so as to make them apply only to marked accesses.
Signed-off-by: Alan Stern
.
This work is based on an earlier formulation of data races for the
LKMM by Andrea Parri.
Signed-off-by: Alan Stern
---
tools/memory-model/linux-kernel.bell |1
tools/memory-model/linux-kernel.cat | 50 ++-
tools/memory-model/linux-kernel.def |1
3
any functional changes.
Signed-off-by: Alan Stern
---
tools/memory-model/linux-kernel.cat | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
Index: usb-devel/tools/memory-model/linux-kernel.cat
===
--- usb
Alexandru Gagniuc writes:
> These switches are used to fornicate the motherboard's x16 PCIe ports
^
I don't think that's the word you intended to use.
--
Alan J. Wylie https://www.wylie.me.uk/
D
s it guarantees ordering of
> accesses on the other side of the atomic operation from the
> smp_mb__{before,after}_atomic(). This commit therefore weakens
> the guarantee to match the semantics called out above.
>
> Reported-by: Andrea Parri
> Suggested-by
the actual ordering implications clear,
and also to explain how these barriers differ from a RELEASE or
ACQUIRE ordering.
Signed-off-by: Alan Stern
---
Documentation/atomic_t.txt | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
Index: usb-devel/Documentation/atomic_t.txt
pdate
that file.
In addition, it's noteworthy that smp_mb__after_spinlock and
smp_mb__after_unlock_lock do not behave in this way.
Alan
that on x86, atomic_inc() acts as a full memory barrier
but not as a compiler barrier, and vice versa for
smp_mb__after_atomic()? Or that neither atomic_inc() nor
smp_mb__after_atomic() implements a full memory barrier?
Either one seems like a very dangerous situation indeed.
Alan
>
On Mon, 15 Apr 2019, Jesse Hathaway wrote:
> On Sat, Apr 6, 2019 at 10:32 AM Alan Stern wrote:
> > Well, at least that's forward progress. I don't know what pstore is or
> > what connection it has to the USB subsystem. Does the machine hang
> > similarly if y
On Thu, Apr 11, 2019 at 10:06 PM Wu Hao wrote:
>
> On Thu, Apr 11, 2019 at 03:07:35PM -0500, Alan Tull wrote:
> > On Sun, Mar 24, 2019 at 10:24 PM Wu Hao wrote:
> >
> > Hi Hao,
> >
> > >
> > > This patch adds support for power management private
gt; > - if (dma_mapping_error(&pdata->dev->dev, region->iova)) {
> > > + if (dma_mapping_error(dfl_fpga_pdata_to_parent(pdata),
> > > region->iova)) {
> > > dev_err(&pdata->dev->dev, "failed to map for dma\n");
> > > ret = -EFAULT;
> > > goto unpin_pages;
> > > --
> > > 1.8.3.1
>
> Acked-by: Moritz Fischer
Acked-by: Alan Tull
>
> Thanks
> Moritz
Alan
ivers/usb/core/hcd.c | 32
> include/linux/usb/hcd.h | 1 +
> 2 files changed, 33 insertions(+)
Technically this patch looks okay to me. However, Greg KH may have
some comments regarding the new uevent this introduces.
Acked-by: Alan Stern
Alan St
On Mon, 15 Apr 2019, Paul E. McKenney wrote:
> Another question is "should the kernel permit smp_mb__{before,after}*()
> anywhere other than immediately before or after the primitive being
> strengthened?"
>
> Thoughts?
How would the kernel forbid other constructions?
Alan
multiple dfl private features.
> >
> > Signed-off-by: Xu Yilun
> > Signed-off-by: Wu Hao
> Acked-by: Moritz Fischer
Acked-by: Alan Tull
Thanks,
Alan
and reset port for error clearing.
> >
> > Signed-off-by: Xu Yilun
> > Signed-off-by: Wu Hao
> Acked-by: Moritz Fischer
Acked-by: Alan Tull
Thanks,
Alan
t
> > to allow userspace applications to mmap related mmio region and
> > provide STP service.
> >
> > Signed-off-by: Xu Yilun
> > Signed-off-by: Wu Hao
> Acked-by: Moritz Fischer
Acked-by: Alan Tull
Thanks,
Alan
ot;power_mgmt",
> +};
> +
> +static int fme_power_mgmt_init(struct platform_device *pdev,
> + struct dfl_feature *feature)
> +{
> + return sysfs_create_group(&pdev->dev.kobj, &power_mgmt_attr_group);
> +}
> +
> +static void fme_power_mgmt_uinit(struct platform_device *pdev,
> +struct dfl_feature *feature)
> +{
> + sysfs_remove_group(&pdev->dev.kobj, &power_mgmt_attr_group);
> +}
> +
> +static const struct dfl_feature_id fme_power_mgmt_id_table[] = {
> + {.id = FME_FEATURE_ID_POWER_MGMT,},
> + {0,}
> +};
> +
> +static const struct dfl_feature_ops fme_power_mgmt_ops = {
> + .init = fme_power_mgmt_init,
> + .uinit = fme_power_mgmt_uinit,
> +};
> +
> static struct dfl_feature_driver fme_feature_drvs[] = {
> {
> .id_table = fme_hdr_id_table,
> @@ -429,6 +682,10 @@ static struct dfl_feature_driver fme_feature_drvs[] = {
> .ops = &fme_thermal_mgmt_ops,
> },
> {
> + .id_table = fme_power_mgmt_id_table,
> + .ops = &fme_power_mgmt_ops,
> + },
> + {
> .ops = NULL,
> },
> };
> --
> 2.7.4
>
Thanks,
Alan
> good solution, for the same reasons why arm stuff moved to devicetree.
>
> Is it clearer?
>
> I do not know if it important to highlight but those cards are extensible,
> potentially any FMC module could be plugged and this needs a different FPGA,
> with different FPGA devic
struct device *dev = feature->priv;
> +
> + sysfs_remove_groups(&dev->kobj, error_groups);
> + device_unregister(dev);
> +}
> +
> +const struct dfl_feature_id fme_global_err_id_table[] = {
> + {.id = FME_FEATURE_ID_GLOBAL_ERR,},
> + {0,}
> +};
> +
> +const struct dfl_feature_ops fme_global_err_ops = {
> + .init = fme_global_err_init,
> + .uinit = fme_global_err_uinit,
> +};
> diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
> index dafa6580..76cb112 100644
> --- a/drivers/fpga/dfl-fme-main.c
> +++ b/drivers/fpga/dfl-fme-main.c
> @@ -686,6 +686,10 @@ static struct dfl_feature_driver fme_feature_drvs[] = {
> .ops = &fme_power_mgmt_ops,
> },
> {
> + .id_table = fme_global_err_id_table,
> + .ops = &fme_global_err_ops,
> + },
> + {
> .ops = NULL,
> },
> };
> diff --git a/drivers/fpga/dfl-fme.h b/drivers/fpga/dfl-fme.h
> index 7a021c4..5fbe3f5 100644
> --- a/drivers/fpga/dfl-fme.h
> +++ b/drivers/fpga/dfl-fme.h
> @@ -37,5 +37,7 @@ struct dfl_fme {
>
> extern const struct dfl_feature_ops fme_pr_mgmt_ops;
> extern const struct dfl_feature_id fme_pr_mgmt_id_table[];
> +extern const struct dfl_feature_ops fme_global_err_ops;
> +extern const struct dfl_feature_id fme_global_err_id_table[];
>
> #endif /* __DFL_FME_H */
> diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h
> index fbc57f0..6c32080 100644
> --- a/drivers/fpga/dfl.h
> +++ b/drivers/fpga/dfl.h
> @@ -197,12 +197,14 @@ struct dfl_feature_driver {
> * feature dev (platform device)'s reources.
> * @ioaddr: mapped mmio resource address.
> * @ops: ops of this sub feature.
> + * @priv: priv data of this feature.
> */
> struct dfl_feature {
> u64 id;
> int resource_index;
> void __iomem *ioaddr;
> const struct dfl_feature_ops *ops;
> + void *priv;
> };
>
> #define DEV_STATUS_IN_USE 0
> --
> 2.7.4
>
Thanks,
Alan
gned-off-by: Xu Yilun
> Signed-off-by: Wu Hao
Acked-by: Alan Tull
Thanks,
Alan
> ---
> Documentation/ABI/testing/sysfs-platform-dfl-fme | 23
> drivers/fpga/dfl-fme-main.c | 48
>
> 2 files changed, 71 insertions(+)
>
truct dfl_feature_ops port_err_ops = {
> + .init = port_err_init,
> + .uinit = port_err_uinit,
> +};
> diff --git a/drivers/fpga/dfl-afu-main.c b/drivers/fpga/dfl-afu-main.c
> index e727d9b..754729e 100644
> --- a/drivers/fpga/dfl-afu-main.c
> +++ b/drivers/fpga/dfl-afu-main.c
> @@ -528,6 +528,10 @@ static struct dfl_feature_driver port_feature_drvs[] = {
> .ops = &port_afu_ops,
> },
> {
> + .id_table = port_err_id_table,
> + .ops = &port_err_ops,
> + },
> + {
> .ops = NULL,
> }
> };
> diff --git a/drivers/fpga/dfl-afu.h b/drivers/fpga/dfl-afu.h
> index 35e60c5..c3182a2 100644
> --- a/drivers/fpga/dfl-afu.h
> +++ b/drivers/fpga/dfl-afu.h
> @@ -100,4 +100,8 @@ int afu_dma_unmap_region(struct dfl_feature_platform_data
> *pdata, u64 iova);
> struct dfl_afu_dma_region *
> afu_dma_region_find(struct dfl_feature_platform_data *pdata,
> u64 iova, u64 size);
> +
> +extern const struct dfl_feature_ops port_err_ops;
> +extern const struct dfl_feature_id port_err_id_table[];
> +
> #endif /* __DFL_AFU_H */
> --
> 2.7.4
>
Thanks,
Alan
es no purpose. So it satisfies the "very unlikely
> to appear" criteria AFAICS.
Yes, looks fine to me, except that in VLE mode (do we care?)
".long 0x0fe50553" disassembles as
0: 0f e5 se_cmphl r5,r30
2: 05 53 se_mullw r3,r5
No illegal/trap/privileged insn there.
".long 0x0fe5000b" might be better to cover VLE.
--
Alan Modra
Australia Development Lab, IBM
On Mon, Apr 8, 2019 at 11:51 AM Moritz Fischer wrote:
>
> Hi Michal,
>
> On Mon, Apr 08, 2019 at 04:36:15PM +0200, Michal Simek wrote:
> > On 08. 04. 19 16:17, Alan Tull wrote:
> > > On Mon, Apr 8, 2019 at 7:39 AM Nava kishore Manne
> > > wrote:
> > &
On Mon, Apr 8, 2019 at 7:39 AM Nava kishore Manne wrote:
>
> Hi Alan,
>
> Thanks for look into it and providing the ACK.
> I got one minor comments from Moritz Fischer do you want me fix that issue
> now or I can fix it later as it’s a minor comment?
Please fix for Moritz co
uld be a bug in
> > > > the compiler.
> > >
> > > AFAICT, we agreed here. So consider the following test:
> > >
> > > C non-transitive-wmb-2
> > >
> > > {
> > > x=0x0001;
> > > }
> > >
> > > P0(int *x, int *y)
> > > {
> > > *x = 1;
> > > smp_store_release(y, 1);
> > > }
> > >
> > > P1(int *x, int *y, int *z)
> > > {
> > > int r1;
> > >
> > > r1 = smp_load_acquire(y);
> > > if (r1) {
> > > *x = 2;
> > > smp_wmb();
> > > WRITE_ONCE(*z, 1);
> > > }
> > > }
> > >
> > > P2(int *x, int *z)
> > > {
> > > int r3;
> > > int r4 = 0;
> > >
> > > r3 = READ_ONCE(*z);
> > > if (r3) {
> > > smp_rmb();
> > > r4 = READ_ONCE(*x); /* E */
> > > }
> > > }
> > >
> > > exists (2:r3=1 /\ 2:r4=2)
> > >
> > > The proposed model says that this is race-free. Now suppose that the
> > > compiler mapped the two plain writes above as follows:
> > >
> > > *x = 1; --> A:write 0x0001 at x
> > >B:write 0x at (x + 2)
> > >
> > > *x = 2; --> C:write 0x0002 at x
> > >if ((D:read of 2 bytes at (x + 2)) != 0x)
> > >write 0x at (x + 2)
> > >
> > > and consider the execution where 1:r1=1 and 2:r3=1. We know that A and
> > > B propagate to P1 before C and D execute (release/acquire) and that C
> > > propagates to P2 before E executes (wmb/rmb). But what guarantees that
> > > B, say, propagates to P2 before E executes? AFAICT, nothing prevent P2
> > > from reading the value 0x00010002 for x, that is, from reading the least
> > > significant bits from P1's "write 0x0002 at x" and the most significant
> > > bits from the initial write. However, the proposed model doesn't report
> > > the corresponding execution/state.
> >
> > Ah, that is indeed an excellent example! I had not considered
> > mixed-size accesses generated by the compiler.
> >
> > So perhaps it would be better to get rid of the whole notion of super
> > and major writes, and declare that non-transitive-wmb is racy in all
> > its variants.
>
> This makes sense to me.
In the next version...
Alan
gt; the compiler.
>
> AFAICT, we agreed here. So consider the following test:
>
> C non-transitive-wmb-2
>
> {
> x=0x0001;
> }
>
> P0(int *x, int *y)
> {
> *x = 1;
> smp_store_release(y, 1);
> }
>
> P1(int *x, int *y, int *z)
> {
> int r1;
>
> r1 = smp_load_acquire(y);
> if (r1) {
> *x = 2;
> smp_wmb();
> WRITE_ONCE(*z, 1);
> }
> }
>
> P2(int *x, int *z)
> {
> int r3;
> int r4 = 0;
>
> r3 = READ_ONCE(*z);
> if (r3) {
> smp_rmb();
> r4 = READ_ONCE(*x); /* E */
> }
> }
>
> exists (2:r3=1 /\ 2:r4=2)
>
> The proposed model says that this is race-free. Now suppose that the
> compiler mapped the two plain writes above as follows:
>
> *x = 1; --> A:write 0x0001 at x
>B:write 0x at (x + 2)
>
> *x = 2; --> C:write 0x0002 at x
>if ((D:read of 2 bytes at (x + 2)) != 0x)
>write 0x at (x + 2)
>
> and consider the execution where 1:r1=1 and 2:r3=1. We know that A and
> B propagate to P1 before C and D execute (release/acquire) and that C
> propagates to P2 before E executes (wmb/rmb). But what guarantees that
> B, say, propagates to P2 before E executes? AFAICT, nothing prevent P2
> from reading the value 0x00010002 for x, that is, from reading the least
> significant bits from P1's "write 0x0002 at x" and the most significant
> bits from the initial write. However, the proposed model doesn't report
> the corresponding execution/state.
Ah, that is indeed an excellent example! I had not considered
mixed-size accesses generated by the compiler.
So perhaps it would be better to get rid of the whole notion of super
and major writes, and declare that non-transitive-wmb is racy in all
its variants.
Alan
es.
At present, however, it does not.
Alan Stern
On Thu, 4 Apr 2019, Jesse Hathaway wrote:
> On Tue, Apr 2, 2019 at 9:29 AM Alan Stern wrote:
> > Most likely the problem occurs somewhere inside
> > quirk_usb_handoff_xhci(). Can Jesse add debugging statements to that
> > routine in order to pin down exactly where the pr
cause there is a smp_mb() between the 2 plain writes in P0()
> > and P1() did establish that r1 is 1 in the positive case. :-/. I am surely
> > missing something :-)
> >
> > ---8<---
> > C Joel-put_pid
> >
> > {}
> >
>
On Wed, Apr 3, 2019 at 3:08 PM Moritz Fischer wrote:
>
> On Wed, Apr 03, 2019 at 01:37:51PM -0500, Alan Tull wrote:
> > >
> > > it's state, not status for most fpga manager drivers. It should
> > > return 'operating' if everything went well.
&g
On Wed, Apr 3, 2019 at 1:05 PM Alan Tull wrote:
>
> On Wed, Apr 3, 2019 at 11:47 AM Moritz Fischer wrote:
> >
> > Hi Richard,
> >
> > On Wed, Apr 03, 2019 at 11:43:26AM -0500, Richard Gong wrote:
> > > Hi Moritz,
> > >
> > >
> >
On Wed, Apr 3, 2019 at 11:47 AM Moritz Fischer wrote:
>
> Hi Richard,
>
> On Wed, Apr 03, 2019 at 11:43:26AM -0500, Richard Gong wrote:
> > Hi Moritz,
> >
> >
> > On 4/3/19 9:20 AM, Moritz Fischer wrote:
> > > Hi Richard,
> > >
> > > On Tue, Apr 02, 2019 at 05:25:43PM -0500, richard.g...@linux.int
);
>
> That info is available in FPGA manager's sysfs status entry, if at all
> I'd make this a dev_dbg().
>
> From my end I don't see how we need this really.
I'm ok with adding a message. It's not adding lots of messages, just
one line for an event that will only happen for people who care about
the event (not too many FPGA users but if someone is using FPGA, they
will care about this.)
Alan
>
> Thanks,
> Moritz
On Tue, Apr 2, 2019 at 7:32 AM Nava kishore Manne wrote:
Hi Nava,
Looks good.
>
> This patch adds FPGA Manager support for the Xilinx
> ZynqMP chip.
>
> Signed-off-by: Nava kishore Manne
Acked-by: Alan Tull
> ---
> Changes for v4:
> -Updated the Fpga
On Tue, 2 Apr 2019, Andrea Parri wrote:
> On Tue, Mar 19, 2019 at 03:38:19PM -0400, Alan Stern wrote:
> > LKMM maintainers and other interested parties:
> >
> > Here is my latest proposal for extending the Linux Kernel Memory Model
> > to handle plain accesses an
or later revisions, userclock setting is moved
> to a separated private feature, so one revision sysfs interface
> is exposed to userspace application for this purpose too.
>
> Signed-off-by: Ananda Ravuri
> Signed-off-by: Russ Weight
> Signed-off-by: Xu Yilun
> Signed-off-by: Wu Hao
Acked-by: Alan Tull
> create mode 100644
> > Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt
> >
>
> Reviewed-by: Rob Herring
Acked-by: Alan Tull
d of course argue that this data race is harmless, especially
> > if X is a single byte. But the more I talk to compiler writers, the
> > less comfortable I become with data races in general. :-/
> >
> > So I would also feel better if the "Y = 1" was WRITE_ONCE().
> >
ol
dependencies. So for example, if your pseudo-code for CPU_1 got
compiled to object code equivalent to:
if (READ_ONCE(Y)) {
if (X != 2)
X = 2;
}
then the CPU might read the value of X before reading the value of Y.
This might not look l
ice of given port back to PF, it configures
>PF/VF access mode to PF, then adds port platform device back to
>re-enable related userspace interfaces on PF.
>
> Signed-off-by: Zhang Yi Z
> Signed-off-by: Xu Yilun
> Signed-off-by: Wu Hao
Acked-by: Alan Tull
gt; Signed-off-by: Xu Yilun
> Signed-off-by: Wu Hao
Acked-by: Alan Tull
On Mon, Mar 25, 2019 at 7:44 PM Wu Hao wrote:
>
> On Mon, Mar 25, 2019 at 12:50:40PM -0500, Alan Tull wrote:
> > On Sun, Mar 24, 2019 at 10:23 PM Wu Hao wrote:
> >
> > Hi Hao,
> >
> > Looks good, one question below.
> >
> > >
> > > Curr
y transient APx state,
> and manage AFU's LTR (latency tolerance reporting).
>
> Signed-off-by: Ananda Ravuri
> Signed-off-by: Xu Yilun
> Signed-off-by: Wu Hao
Acked-by: Alan Tull
Thanks,
Alan
src should be const, and the asm statement should have a memory
> > clobber.
> >
> > > +#else
> > > +static inline void copy512(void *src, void __iomem *dst)
> > > +{
> > > + WARN_ON_ONCE(1);
> > > +}
> > > +#endif
> >
> &g
r test
> result.
>
> Please note now this optimization is only done on revision 2
> of this PR private feature which is only used in integrated
> solution that AVX512 is always supported.
>
> Signed-off-by: Ananda Ravuri
> Signed-off-by: Xu Yilun
> Signed-off-by: Wu Hao
Acked-by: Alan Tull
res the extra padding
> +* data automatically.
> +*/
> + length = ALIGN(port_pr.buffer_size, 4);
> +
> + buf = vmalloc(length);
Since it may not be completely filled, would it be worthwhile to alloc
a zero'ed buff?
Alan
> if (!buf)
>
by: Wu Hao
Acked-by: Alan Tull
Thanks,
Alan
> ---
> drivers/fpga/dfl-fme-mgr.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/fpga/dfl-fme-mgr.c b/drivers/fpga/dfl-fme-mgr.c
> index 76f3770..b3f7eee 100644
> --- a/drivers/fpga/dfl-fme-m
ed long pfn_base;
> +EXPORT_SYMBOL(pfn_base);
> +
> pgd_t swapper_pg_dir[PTRS_PER_PGD] __page_aligned_bss;
> pgd_t trampoline_pg_dir[PTRS_PER_PGD] __initdata __aligned(PAGE_SIZE);
>
> --
> 2.17.1
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
Alan
e timing (0x44) so
should indeed be ata_piix.
Alan
A memory save operation to 8-byte variable in RV32 is divided into
two sw instructions in the put_user macro. The current fixup returns
execution flow to the second sw instead of the one after it.
This patch fixes this fixup code according to the load access part.
Signed-off-by: Alan Kao
Cc
* Liu Bo (obuil.li...@gmail.com) wrote:
> On Mon, Dec 10, 2018 at 9:57 AM Vivek Goyal wrote:
> >
> > Instead of assuming we had the fixed bar for the cache, use the
> > value from the capabilities.
> >
> > Signed-off-by: Dr. David Alan Gilbert
>
e of the ideas below were originally proposed for the LKMM by Andrea
Parri.
Alan
---
A Plan For Modeling Plain Accesses In The Linux Kernel Memory Model
Definition: A "plain" access is one which is not "marked&q
ly thing that can stall a kernel thread when accessing a memory location,
it's one of the few that never needs priviledge.
Add a flag, allowing userfaultfd to be restricted, so that in general
it won't be useable by arbitrary user programs, but in environments that
require userf
ted with the current console.
* Invoked by ioctl().
*
* Locking: called without locks. Calls the ldisc wrongly with
* unsafe methods,
*/
from which I deduce that with everyone using X nobody ever bothered to
fix it. So before you look too hard at the speakup code you might want to
review the interaction with selection.c too.
Alan
> Suse have a solution for this that I'd like to see pushed again, but
> from a practical perspective enterprise distributions have been
> shipping this for some time without significant obvious customer
> complaint.
Probably because their IT department hasn't noticed 8)
Alan
Greg KH writes:
> On Thu, Mar 14, 2019 at 02:52:50PM -0700, Greg KH wrote:
>> On Thu, Mar 14, 2019 at 08:43:14PM +0000, Alan J. Wylie wrote:
>> >
>> > (Adding Linus, since his tree is also broken)
>>
>> Again, can you try running 'git bisect'
(Adding Linus, since his tree is also broken)
Greg KH writes:
> On Thu, Mar 14, 2019 at 07:59:00PM +0000, Alan J. Wylie wrote:
>> Greg KH writes:
>>
>> > I'm announcing the release of the 5.0.2 kernel.
>>
>> There is a regression for AMD-only
; /* Not in process context, so don't try to reset the controller */
No, you are misinterpreting that comment. It doesn't mean resetting
the controller in order to make the hardware start working again; it
means resetting the controller to make sure that the hardware is idle
and i
at also mean actual
Sparc hardware has it. In which case presumably it needs fixing, or at
least moving to the generic driver assuming the firmware sets it up ?
Alan
se. And in those cases
> we cannot depend on upper layers doing the right thing, if
> we just ignore an error.
>
> NACK
>
> Sorry
> Oliver
Note that the reset routines in usb-storage do not make any exceptions
for -ENODEV.
Alan Stern
disable it when the
> kernel is locked down.
That one is a bit worrying since whilst the other stuff may be useful in
some business environments, mandatory hibernate not suspend to RAM is a
common corporate IT policy because of concerns about theft and recovery
of memory contents.
Alan
't Minix 1.0 use a.out? It *is* cool to be able to binaries from
> run dead operating systems. :-)
Minixemu compiled fine ELF last time I checked 8). It does need a 32bit
system as it still uses virtual 86 model.
Alan
actually has an a.out binary they
can't live with they can also just write an a.out loader as an ELF
program entirely in userspace.
I'd vote for giving it the boot unless there are any architectures that
kept using a.out far longer due to tool chain issues ?
Alan
rfi" to indicate that
> the ordering guarantees being relied upon are subtle and error-prone, and
> therefore should only be considered for fast-path code?
Unfortunately, herd can't really tell whether a particular ordering is
being _used_; it can only tell when the ordering is present. Therefore
such a flag would be prone to false positives.
Alan
WRITE_ONCE(*z, r0);
> r1 = smp_load_acquire(z);
> r2 = READ_ONCE(*x);
> }
>
> exists (1:r0=1 /\ 1:r2=0)
>
> Signed-off-by: Andrea Parri
> Cc: Alan Stern
> Cc: Will Deacon
> Cc: Peter Zijlstra
> Cc: Boqun Feng
> Cc: Nicholas Piggin
> Cc: D
nk training finishes.
>
> Catching the port in link training (polling) and adding the debounce delay
> prevents unnecessary failed attempts to autosuspend the hub.
>
> Signed-off-by: Mathias Nyman
> Acked-by: Alan Stern
> Signed-off-by: Greg Kroah-Hartman
> Signed-off-by: Sasha
[Added LKML to CC: -- I forgot to include it originally]
On Fri, 15 Feb 2019, Will Deacon wrote:
Thanks a lot for the quick feedback.
> Hi Alan,
>
> I'll give you my opinions below, but my broader concern here is that the
> compiler folks will be reluctant to guarantee very
+ fpga_mgr_free(mgr);
With devm_fpga_mgr_create(), this fpga_mgr_free() can go away.
> > + return err;
> > + }
> > +
> > + return 0;
Thanks,
Alan
On Mon, Feb 11, 2019 at 1:13 PM Greg Kroah-Hartman
wrote:
>
> On Mon, Feb 11, 2019 at 12:41:40PM -0600, Alan Tull wrote:
> > On Fri, Nov 9, 2018 at 12:58 AM Frank Rowand wrote:
> >
> > What LTSI's are these patches likely to end up in? Just to be clear,
> &g
On Fri, Nov 9, 2018 at 12:58 AM Frank Rowand wrote:
What LTSI's are these patches likely to end up in? Just to be clear,
I'm not pushing for any specific answer, I just want to know what to
expect.
Thanks,
Alan
>
> On 11/8/18 10:56 PM, Frank Rowand wrote:
> > Hi Rob,
&
;s been
initialized via __metadata_dst_init alright.
I think the fix here is to use skb_valid_dst(skb) - it checks
for DST_METADATA also, and with that fix in place, the
problem - which was previously 100% reproducible - disappears.
However what we should do in terms of path MTU setting for
such
e is copied field by field.
>
> The usb code is updated to track if the values it passes into
> kill_pid_usb_asyncio were passed to it from a native userspace
> or from at compat user space. To allow a proper conversion
> of the addresses.
>
> Cc: Greg Kroah-Har
On Mon, 4 Feb 2019, John Stultz wrote:
> On Sat, Feb 2, 2019 at 9:00 AM Alan Stern wrote:
> >
> > On Fri, 1 Feb 2019, John Stultz wrote:
> >
> > > Hey all,
> > > Since the 5.0 merge window opened, I've been tripping on frequent
> > > dw
data
>
> arch/arm/mach-davinci/board-da830-evm.c | 73 ++--
> arch/arm/mach-davinci/board-omapl138-hawk.c | 81 ++
> drivers/usb/host/ohci-da8xx.c | 118 ++--
> include/linux/platform_data/usb-davinci.h | 14 ---
> 4 files changed, 77 insertions(+), 209 deletions(-)
For patches 1, 2, 5, and 8:
Acked-by: Alan Stern
Hello, Thomas.
On Mon, Feb 04, 2019 at 17:25:11 +, Thomas Gleixner wrote:
> On Sat, 2 Feb 2019, Alan Mackenzie wrote:
[ ]
> > I've just built and installed Linux 4.19.19, and it does indeed solve
> > the Emacs profiler bug, #34235. :-)
> > I see that the p
stopping the irq from happening?
Certainly. usb_ep_dequeue() just speeds up the process of completing
the request; it doesn't wait for that process to finish.
Alan Stern
> If I revert all the changes to dwc3 back to 4.20, I don't see the issue.
>
> I'll do some bisection to try to narrow things down, but I wanted to
> see if this was a known issue or if anyone had immediate ideas as to
> what might be wrong.
>
> thanks
> -john
Hello, Thomas.
Thanks for such a rapid reply!
On Fri, Feb 01, 2019 at 23:04:48 +0100, Thomas Gleixner wrote:
> Hello Alan,
> On Fri, 1 Feb 2019, Alan Mackenzie wrote:
> > 0e334db6bb4b1fd1e2d72c1f3d8f004313cd9f94
> > posix-timers: Fix division by zero bug
> > Committed: 2
n
Emacs and glibc, or between glibc and Linux, or that there is some
intrinsic problem with the patch.
I have very little familiarity with glibc and Linux source code, so I
would be greatful if you could help me investigate the bug scenario.
Naturally, I will help as I can in this process.
Thanks in advance!
--
Alan Mackenzie (Nuremberg, Germany).
is nothing new - the headers on the files provided no more data on
that and took up lots more space 8) We've simply never tracked licence
data by line.
Alan
t; > + not use in new code.
Actually it was a historic fix for the fact that some slimeballs were
going to use a proposed "BSD" tag and just ship binaries only whilst
claiming that they were totally compliant with the BSD licence.
Alan
t (20564)
/home/atull/repos/linux-socfpga/arch/arm/mach-socfpga/self-refresh.S:103:
Error: bad immediate value for offset (20564)
/home/atull/repos/linux-socfpga/arch/arm/mach-socfpga/self-refresh.S:108:
Error: bad immediate value for offset (20568)
/home/atull/repos/linux-socfpga/scripts/Makefile.build:367: recipe for
target 'arch/arm/mach-socfpga/self-refresh.o' failed
Thanks,
Alan
006918) {
> + pr_warn("fsl-ehci: USB PHY clock invalid\n");
Again, you should use dev_warn() instead of pr_warn().
Alan Stern
> + return -EINVAL;
> + }
> +
> case FSL_USB2_PHY_UTMI_DUAL:
> /* PHY_CLK_
e 100644
> --- a/drivers/usb/host/ehci-fsl.h
> +++ b/drivers/usb/host/ehci-fsl.h
> @@ -50,4 +50,7 @@
> #define UTMI_PHY_EN (1<<9)
> #define ULPI_PHY_CLK_SEL(1<<10)
> #define PHY_CLK_VALID(1<<17)
> +
> +/* Retry count for checking UTMI PHY CLK validity */
> +#define UTMI_PHY_CLK_VALID_CHK_RETRY 5
> #endif /* _EHCI_FSL_H */
Alan Stern
On Fri, 25 Jan 2019, Yinbo Zhu wrote:
> From: Nikhil Badola
>
> Set USB_EN bit to select ULPI phy for USB controller version 2.5
>
> Signed-off-by: Nikhil Badola
> Signed-off-by: Yinbo Zhu
> ---
Acked-by: Alan Stern
> Change in v4:
> Incorrect inde
tly decreasing the refcount on that node
again.
This patch removes the unwarranted call to of_node_put().
Fixes: e7eef1d7633a ("fpga: add intel stratix10 soc fpga manager driver")
Signed-off-by: Nicolas Saenz Julienne
Acked-by: Alan Tull
Acked-by: Moritz Fischer
[atull: remove unneces
On Thu, Jan 24, 2019 at 2:46 PM Alan Tull wrote:
>
> From: Nicolas Saenz Julienne
>
> After finding a "firmware" dt node stratix10 tries to match it's
> compatible string with it. To do so it's calling of_find_matching_node()
> which already takes care of de
ould not be
> changed in each controller driver, but I see both have been used in most
> controller drivers. I will leave this to others to educate me.
In some of the older HCDs, urb->hcpriv != NULL is used to indicate that
urb is on an endpoint queue. Perhaps that usage was copied.
Alan Stern
data bss dec hex filename
72812096 0937724a1 drivers/fpga/altera-ps-spi.o
(gcc version 8.2.0 x86_64)
Signed-off-by: Colin Ian King
Acked-by: Alan Tull
Acked-by: Moritz Fischer
---
drivers/fpga/altera-ps-spi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The Altera Freeze Bridge should not be restricted to ARCH_SOCFPGA
since it can be used on other platforms such as Stratix10.
Signed-off-by: Alan Tull
Reviewed-by: Moritz Fischer
---
drivers/fpga/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/fpga/Kconfig b
ther two can go in whenever is appropriate.
Thanks,
Alan
Alan Tull (1):
fpga: altera_freeze_bridge: remove restriction to socfpga
Colin Ian King (1):
fpga: mgr: altera-ps-spi: make array dummy static, shrinks object size
Nicolas Saenz Julienne (1):
fpga: stratix10-soc: fix wrong of_nod
tly decreasing the refcount on that node
again.
This patch removes the unwarranted call to of_node_put().
Fixes: e7eef1d7633a ("fpga: add intel stratix10 soc fpga manager driver")
Signed-off-by: Nicolas Saenz Julienne
Acked-by: Alan Tull
Acked-by: Moritz Fischer
---
drivers/fpga/s
ec hex filename
>73712032 0940324bb drivers/fpga/altera-ps-spi.o
>
> After:
>textdata bss dec hex filename
>72812096 0937724a1 drivers/fpga/altera-ps-spi.o
>
> (gcc version 8.2.0 x86_64)
>
> Signed-off-by:
On Mon, 14 Jan 2019, Paul Elder wrote:
> On Fri, Jan 11, 2019 at 10:50:11AM -0500, Alan Stern wrote:
> > On Fri, 11 Jan 2019, Paul Elder wrote:
> >
> > > On Wed, Jan 09, 2019 at 02:06:31PM -0500, Alan Stern wrote:
> > > > On Wed, 9 Jan 2019, Paul Elder wr
06918 =
> + of_property_read_bool(np, "fsl,usb_erratum-a006918");
> + pdata->has_fsl_erratum_14 =
> + of_property_read_bool(np, "fsl,usb_erratum-14");
Why go to the trouble of adding bad code for has_fsl_erratum_a006918 in
patch 4/5 if you're going to change that code here? Why not just add
the correct code in the first place?
Alan Stern
>
> /*
>* Determine whether phy_clk_valid needs to be checked
>
801 - 900 of 9576 matches
Mail list logo
