v2:
kbuild test robot feedback: correct
"warning: comparison of distinct pointer types lacks a cast"
build warning on some compilers / architectures.
v1:
original patch
Sven Van Asbroeck (1):
at24: support eeproms that do not roll over
device_id table, or add 'no-read-rollover' to the eeprom
devicetree entry.
Signed-off-by: Sven Van Asbroeck
---
.../devicetree/bindings/eeprom/eeprom.txt | 5 +++
drivers/misc/eeprom/at24.c | 47 +++---
include/linux/platform_d
device_id table, or add 'no-read-rollover' to the eeprom
devicetree entry.
Signed-off-by: Sven Van Asbroeck
---
.../devicetree/bindings/eeprom/eeprom.txt | 5 +++
drivers/misc/eeprom/at24.c | 46 +++---
include/linux/platform_d
Rob, thank you so much for the review !
On Mon, Nov 26, 2018 at 5:08 PM Rob Herring wrote:
> Unit-addresses are based on 'reg'. So this should either be '89' or
> based on a definition for the bus (e.g. PCI uses dev and func).
>
>> + reg = <0x0089>;
>
> Is fieldbus type how o
Wow Greg, thanks for the review, this is awesome !!
On Tue, Nov 27, 2018 at 2:54 AM Greg KH wrote:
>> + cdev_init(&fb->cdev, &fieldbus_fops);
>> + err = cdev_add(&fb->cdev, devno, 1);
>> + if (err) {
>> + pr_err("fieldbus_dev%d unable to add device %d:%d\n",
>> +
On Wed, Nov 28, 2018 at 12:42 PM Greg KH wrote:
> It depends on what you want to do with this device node. You can use a
> static one in your structure if you use it to "cast back" to your real
> structure in the open() call, do you do that?
I do...
static int fieldbus_open(struct inode *inode
On Wed, Nov 28, 2018 at 1:36 PM Greg KH wrote:
> So you still need a char device, and you will have have a load of them,
> just use the misc device api. It's simple, clean, and is hard to get
> wrong. The cdev api is hard, complex, and trivial to get wrong in any
> number of different ways that
Rob,
Eliminating the 'compatible' property for the anybus gives me an interesting
devicetree problem.
The imx-weim code naively loops through all subnodes, applying timing settings
to the CS in the first reg entry.
In the example below, WEIM CS0 is programmed with the settings in
fsl,weim-cs-timi
On Thu, Nov 8, 2018 at 9:07 AM Arnd Bergmann wrote:
>
>
> > +struct anybuss_host {
> > + struct device *dev;
> > + struct anybuss_client *client;
> > + struct reset_control *reset;
> > + struct regmap *regmap;
> > + int irq;
> > + struct task_struct *qthread;
>
On Thu, Nov 8, 2018 at 9:27 AM Arnd Bergmann wrote:
>
> We do the same thing on PCI and USB, where normally everything
> is probed through hardware access, but a device driver can look
> at dev->of_node to see if that contains any further properties.
>
This is very interesting. Spent some time tr
-off-by: Sven Van Asbroeck
---
drivers/fieldbus/Kconfig |3 +-
drivers/fieldbus/Makefile |4 +-
drivers/fieldbus/anybuss/Kconfig |9 +
drivers/fieldbus/anybuss/Makefile |7 +
drivers/fieldbus/anybuss/host.c| 1459
include/linux
place devicetree functions with more generic platform_get_resource()
platform_get_irq()
added device unique data to add_device_randomness()
v1:
first shot
Sven Van Asbroeck (6):
fieldbus_dev: add Fieldbus Device subsystem.
anybus-s: support HMS Anybus-S bus
anybus-s: support the
From: Sven Van Asbroeck
arcx Inc. is an engineering company which provides advanced
embedded systems and consulting services.
Archronix is a technology design and product engineering firm
specializing in hardware control systems and enabling software.
Clients include OEM's in the transport
From: Sven Van Asbroeck
This patch adds devicetree binding documentation for the
Arcx anybus controller.
Signed-off-by: Sven Van Asbroeck
---
.../fieldbus/arcx,anybus-controller.txt | 71 +++
1 file changed, 71 insertions(+)
create mode 100644
Documentation/devicetree
as a fieldbus_dev,
and userspace can access it through the fieldbus_dev interface.
Signed-off-by: Sven Van Asbroeck
---
drivers/fieldbus/anybuss/Kconfig| 16 ++
drivers/fieldbus/anybuss/Makefile | 1 +
drivers/fieldbus/anybuss/hms-profinet.c | 223
3
s designed to provide a generic interface to Fieldbus
Devices from both the Linux Kernel and the userspace.
Signed-off-by: Sven Van Asbroeck
---
Documentation/ABI/testing/fieldbus-dev-cdev | 31 ++
.../ABI/testing/sysfs-class-fieldbus-dev | 63
Documentation/fieldbus_dev/fieldb
Add a driver for the Arcx anybus controller.
This device implements two Anybus-S hosts (buses),
and connects to the SoC via a parallel memory bus.
There is also a CAN power readout, unrelated to the Anybus,
modelled as a regulator.
Signed-off-by: Sven Van Asbroeck
---
drivers/fieldbus/Makefile
Hello Shawn, many thanks for the patch review, I really appreciate it !
On Wed, Dec 5, 2018 at 2:52 AM Shawn Guo wrote:
>
> On Fri, Nov 30, 2018 at 03:56:23PM -0500, thesve...@gmail.com wrote:
> > From: Sven Van Asbroeck
> >
> > Ensure that timing values for the c
Hello Greg, thanks for the feedback!
On Wed, Dec 5, 2018 at 5:17 AM Greg KH wrote:
> And why is this a class and not just a "normal" device and bus? Devices
> live on busses, not generally as a class. Can your devices live on
> different types of busses (USB, PCI, etc.)?
This patchset can be a
Thanks :)
On Wed, Dec 5, 2018 at 2:17 PM Greg KH wrote:
>
> Great, then call it a 'fieldbus' class, not "fieldbus_dev' class.
Small nit:
Hardware connected to a fieldbus comes in two distinct flavours:
- clients (e.g. thermometer, robotic arm) called "fieldbus devices"
- servers (e.g. a PLC) ca
Hi Greg,
On Thu, Dec 6, 2018 at 9:07 AM Greg KH wrote:
>
> And as these are really devices, why not make them a "device" and a bus?
> What type of topology do you have on these busses? Are everything
> "flat" and connected directly to a PCI/USB/platform device? Or are
> there multiple devices a
Hi David, thank you for the feedback !
On Wed, Dec 5, 2018 at 9:05 PM David Lechner wrote:
>
> Does this actually need a new fieldbus subsystem or could it just be
> implemented as a new network protocol?
>
> Then this generic interface to a fieldbus device could just be a socket.
>
This is a fu
e = "acme,whatever";
reg = <0 0 0x100>, <0 0x40 0x800>,
<1 0x40 0x800>;
fsl,weim-cs-timing = <0x024400b1 0x1010 0x20081100
0x 0xa240 0x0000>;
Support multiple address ranges per child node on imx-weim.
While we're at it, insert some code which guards against common config
conflicts.
v3:
added devicetree binding docs
v2:
corrected acme@... in commit message example
Sven Van Asbroeck (3):
bus: imx-weim: su
The imx-weim driver was patched to allow correct WEIM configuration
when multiple address ranges are used in a child node.
Update the dt-bindings to reflect this.
Signed-off-by: Sven Van Asbroeck
---
.../devicetree/bindings/bus/imx-weim.txt | 32 +--
1 file changed, 29
= <0 0 0x100>;
fsl,weim-cs-timing = ;
};
acme@1 {
compatible = "acme,whatnot";
reg = <0 0x500 0x100>;
fsl,weim-cs-timing = ;
};
};
Signed-off-by: Sven Van Asbroeck
---
drivers/bus/imx-weim.c | 3
Arnd, Rob, Linus,
Many thanks for your constructive feedback so far !
Is there anything in general about this set that would prevent it from being
mainlined? Perhaps I am trying to do too much at once, dropping a patchset
that is too complex to be properly reviewed?
I've been thinking about rewo
On Thu, Nov 8, 2018 at 9:07 AM Arnd Bergmann wrote:
>
> > +struct anybus_mbox_hdr {
> > + u16 id;
> > + u16 info;
> > + u16 cmd_num;
> > + u16 data_size;
> > + u16 frame_count;
> > + u16 frame_num;
> > + u16 offset_high;
> > + u16 offset_low;
> > +
On Fri, Nov 9, 2018 at 4:22 PM Arnd Bergmann wrote:
>
>
> As usual, it comes down to the user space interfaces I think. Designing
> a user interface is hard, most importantly because you cannot change it
> once anyone starts relying on it, as opposed to implementation details
> that you are free t
tg3 :03:00.0 eth20: 0: NAPI info
[::(0001::01ff)::(00c8:::)]
[ 32.521509] tg3 :03:00.0: tg3_stop_block timed out, ofs=1400 enable_bit=2
[ 32.533646] tg3 :03:00.0 eth20: Link is down
[ 32.551044] tg3 :03:00.0 eth20: Link is down
Signed
Thank you Trent !
This patch was intended as a bug report, rather than an actual
solution to be merged.
I chose this format so people could easily verify the change in
behaviour, just by
applying the patch locally.
On Tue, Dec 18, 2018 at 6:06 PM Trent Piepho wrote:
>
>
> It's actually commit f3
This patch seems to fix the regression on my board: i.MX6 with a
tg3-based pcie NIC:
CPU identified as i.MX6Q, silicon rev 1.5
tg3 :03:00.0 eth0: Tigon3 [partno(BCM57780) rev 57780001] (PCI Express)
Tested-by: Sven Van Asbroeck
On Wed, Dec 19, 2018 at 12:25 AM Richard Zhu wrote
using #define'd constant name
minor coding style fixes
v3:
added devicetree binding docs
v2:
corrected acme@... in commit message example
Sven Van Asbroeck (3):
dt-bindings: bus: imx-weim: document multiple address ranges per child
node
bus: imx-weim: support multip
= <0 0 0x100>;
fsl,weim-cs-timing = ;
};
acme@1 {
compatible = "acme,whatnot";
reg = <0 0x500 0x100>;
fsl,weim-cs-timing = ;
};
};
Signed-off-by: Sven Van Asbroeck
---
drivers/bus/imx-weim.c | 35
The imx-weim driver was patched to allow correct WEIM configuration
when multiple address ranges are used in a child node.
Update the dt-bindings to reflect this.
Reviewed-by: Rob Herring
Signed-off-by: Sven Van Asbroeck
---
.../devicetree/bindings/bus/imx-weim.txt | 32
e = "acme,whatever";
reg = <0 0 0x100>, <0 0x40 0x800>,
<1 0x40 0x800>;
fsl,weim-cs-timing = <0x024400b1 0x1010 0x20081100
0x 0xa240 0x0000>;
ences 'i.MX WEIM parallel bus' to 'parallel bus'
replace devicetree functions with more generic platform_get_resource()
platform_get_irq()
added device unique data to add_device_randomness()
v1:
fir
s designed to provide a generic interface to Fieldbus
Devices from both the Linux Kernel and the userspace.
Signed-off-by: Sven Van Asbroeck
---
Documentation/ABI/testing/fieldbus-dev-cdev | 31 ++
.../ABI/testing/sysfs-class-fieldbus-dev | 62
Documentation/fieldbus_dev/fieldb
From: Sven Van Asbroeck
arcx Inc. is an engineering company which provides advanced
embedded systems and consulting services.
Archronix is a technology design and product engineering firm
specializing in hardware control systems and enabling software.
Clients include OEM's in the transport
as a fieldbus_dev,
and userspace can access it through the fieldbus_dev interface.
Signed-off-by: Sven Van Asbroeck
---
drivers/fieldbus/anybuss/Kconfig| 16 ++
drivers/fieldbus/anybuss/Makefile | 1 +
drivers/fieldbus/anybuss/hms-profinet.c | 223
3
From: Sven Van Asbroeck
This patch adds devicetree binding documentation for the
Arcx anybus controller.
Signed-off-by: Sven Van Asbroeck
---
.../fieldbus/arcx,anybus-controller.txt | 71 +++
1 file changed, 71 insertions(+)
create mode 100644
Documentation/devicetree
-off-by: Sven Van Asbroeck
---
drivers/fieldbus/Kconfig |3 +-
drivers/fieldbus/Makefile |4 +-
drivers/fieldbus/anybuss/Kconfig |9 +
drivers/fieldbus/anybuss/Makefile |7 +
drivers/fieldbus/anybuss/host.c| 1459
include/linux
Add a driver for the Arcx anybus controller.
This device implements two Anybus-S hosts (buses),
and connects to the SoC via a parallel memory bus.
There is also a CAN power readout, unrelated to the Anybus,
modelled as a regulator.
Signed-off-by: Sven Van Asbroeck
---
drivers/fieldbus/Makefile
On Tue, Nov 6, 2018 at 8:58 AM Rob Herring wrote:
> It doesn't really sound like the host should be in DT. The bridge
> should register itself as an anybus provider and that should in turn
> enable the anybus host protocol.
Very good point. Just to make sure we're on the same page, could you poi
On Tue, Nov 6, 2018 at 1:31 PM Rob Herring wrote:
> If the host is not a h/w component, but just a s/w protocol then it
> doesn't belong in DT. Perhaps it could be a library which the bridge
> driver can call into.
Anybus cards have an id register, which identifies what they are, so
that the app
Hi Arnd, thank you for the review and the feedback !
>
> To allow describing connected devices, I think we need a #address-cells
> and #size-cells property here, with fixed values.
I'm not sure I understand. Connected devices aren't described in the
devicetree. The anybus specification defines an
Hi Arnd,
These are great questions, I had been wondering when they would be brought up :)
On Thu, Nov 8, 2018 at 9:20 AM Arnd Bergmann wrote:
>
> I don't understand much about field bus, but I have a general feeling
> that if you configure a mac address and IP address, this should
> be connect e
On Thu, Nov 8, 2018 at 9:07 AM Arnd Bergmann wrote:
>
> It looks like you build your own object management here. Maybe
> use kobject, or at least kref instead of the refcount_t based
> low-level implementation?
Excellent point. I'll replace with krefs.
>
>
> I see this is called from the interru
Hi Linus,
> This is fun :)
It sure is ! It's fascinating to see how the kernel abstractions are designed,
and how code is reviewed here.
>> +static DEVICE_ATTR_RO(version);
>
> Do you need this in userspace really?
>
>> +static DEVICE_ATTR_RO(design_number);
>
> And this?
Unfortunately, I do :(
On Thu, Nov 1, 2018 at 5:53 PM Linus Walleij wrote:
>
> On Thu, Nov 1, 2018 at 6:17 PM Sven Van Asbroeck wrote:
> > Perhaps there is another kernel abstraction I could use?
>
> Maybe the properties should be on the bus though? I don't know :/
Let's keep the versio
On Fri, Nov 2, 2018 at 1:12 PM wrote:
>
> Add support for PF0100 coin cell/super capacitor charger which works as
Cancel this. A patch for this has already been submitted by Adam Ford:
https://patchwork.kernel.org/patch/10661227/
Not sure why it didn't show up in my search.
Sven
Thanks for your feedback, I appreciate it !
On Thu, Oct 25, 2018 at 5:19 AM Andy Shevchenko
wrote:
>
> I highly recommend to look at my recent (for few month?) reviews -- they are
> almost repeating each other.
>
> Also check what we have under lib/ (hint: read linux/kernel.h for inline and
> ex
On Mon, Nov 5, 2018 at 4:20 PM Rob Herring wrote:
>
> bridge vs. host are confusing me as those are often the same thing. But
> here bridge is just some auxilliary controls for the bus and the host is
> the actual bus with devices? I'm not sure why you split this into 2 DT
> nodes? How many device
Add a driver for the Arcx anybus bridge.
This chip embeds up to two Anybus-S application connectors
(slots), and connects to the SoC via the i.MX parallel WEIM bus.
There is also a CAN power readout, unrelated to the anybus.
Signed-off-by: Sven Van Asbroeck
---
drivers/mfd/Kconfig
This patch adds devicetree binding documentation for the
Arcx anybus bridge.
Signed-off-by: Sven Van Asbroeck
---
.../bindings/mfd/arcx,anybus-bridge.txt | 37 +++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
2 files changed, 38 insertions(+)
create mode 100644
.
v1:
first shot
Sven Van Asbroeck (4):
mfd: support the Arcx anybus bridge.
dt-bindings: anybus-bridge: document devicetree binding.
bus: support HMS Anybus-S bus.
misc: support HMS Profinet IRT industrial controller.
.../bindings/mfd/arcx,anybus-bridge.txt | 37 +
...
function.
Signed-off-by: Sven Van Asbroeck
---
drivers/bus/Kconfig| 11 +
drivers/bus/Makefile |1 +
drivers/bus/anybuss-host.c | 1301
include/linux/anybuss-client.h | 100 +++
4 files changed, 1413 insertions(+)
create mode 100644
can be accessed via
the sysfs dir.
Signed-off-by: Sven Van Asbroeck
---
drivers/misc/Kconfig | 11 +
drivers/misc/Makefile | 1 +
drivers/misc/hms-profinet.c | 747 ++
include/uapi/linux/hms-common.h | 14 +
include/uapi/linux/
> Wow, this driver is going to need a lot of work.
I'm open to reworking this 5 times if need be :)
>
> But before we get going, how many sub-devices does this have?
This is a custom piece of h/w which exposes two anybus-S slots, plus a
power readout in sysfs, I wasn't quite sure if mfd is the r
Hi Lucas,
On Mon, Feb 15, 2021 at 5:15 AM Lucas Stach wrote:
>
> The straight forward way to fix this would be to just disable the PRE
> when the stride is getting too large, which might not work well with
> all userspace requirements, as it effectively disables the ability to
> scan GPU tiled su
From: Sven Van Asbroeck
Tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git #
9ec5eea5b6ac
v2 -> v3:
- Bryan Whitehead:
+ add Bryan's reviewed-by tag to patch 1/5.
+ Only use FRAME_LENGTH if the LS bit is checked.
If set use the smaller of FRAME_L
From: Sven Van Asbroeck
The buffers in the lan743x driver's receive ring are always 9K,
even when the largest packet that can be received (the mtu) is
much smaller. This performs particularly badly on cpu archs
without dma cache snooping (such as ARM): each received packet
results in a 9K
From: Sven Van Asbroeck
On cpu architectures w/o dma cache snooping, dma_unmap() is a
is a very expensive operation, because its resulting sync
needs to invalidate cpu caches.
Increase efficiency/performance by syncing only those sections
of the lan743x's rx ring buffers that are actual
From: Sven Van Asbroeck
Signed-off-by: Sven Van Asbroeck
---
To: Bryan Whitehead
To: unglinuxdri...@microchip.com
To: "David S. Miller"
To: Jakub Kicinski
Cc: Andrew Lunn
Cc: Alexey Denisov
Cc: Sergej Bauer
Cc: Tim Harvey
Cc: Anders Rønningen
Cc: Hillf Danton
Cc: Christoph H
From: Sven Van Asbroeck
Simulate low-memory in lan743x_rx_trim_skb(): fail one allocation
in every 100.
Signed-off-by: Sven Van Asbroeck
---
To: Bryan Whitehead
To: unglinuxdri...@microchip.com
To: "David S. Miller"
To: Jakub Kicinski
Cc: Andrew Lunn
Cc: Alexey Denisov
Cc: Se
From: Sven Van Asbroeck
Simulate low-memory in lan743x_rx_allocate_skb(): fail 10
allocations in a row in every 100.
Signed-off-by: Sven Van Asbroeck
---
To: Bryan Whitehead
To: unglinuxdri...@microchip.com
To: "David S. Miller"
To: Jakub Kicinski
Cc: Andrew Lunn
Cc: Alexey D
Hi Bryan,
On Tue, Feb 16, 2021 at 3:50 PM wrote:
>
> Looks Good, Thanks Sven
> Our testing is in progress, We will let you know our results soon.
>
> Reviewed-by: Bryan Whitehead
>
Thank you Bryan, I really appreciate your help and expertise.
From: Sven Van Asbroeck
This reverts commit 3e21a10fdea3c2e4e4d1b72cb9d720256461af40.
The reverted patch completely breaks all network connectivity on the
lan7430. tcpdump indicates missing bytes when receiving ping
packets from an external host:
host$ ping $lan7430_ip
lan7430$ tcpdump -v
IP
Hi George,
On Thu, Apr 8, 2021 at 1:36 PM George McCollister
wrote:
>
> Can you explain the difference in behavior with what I was observing
> on the LAN7431?
I'm not using DSA in my application, so I cannot test or replicate
what you were observing. It would be great if we could work together
a
Hi Heiner,
On Thu, Apr 8, 2021 at 1:49 PM Heiner Kallweit wrote:
>
> Can't we use frame_length - ETH_FCS_LEN direcctly here?
If the hard-coded "4" refers to ETH_FCS_LEN, then yes, good point. I'd
love to find out first why George and I need different patches to make
the driver work in our use ca
Hi Heiner,
On Thu, Apr 8, 2021 at 2:22 PM Heiner Kallweit wrote:
>
> Just an idea:
> RX_HEAD_PADDING is an alias for NET_IP_ALIGN that can have two values:
> 0 and 2
> The two systems you use may have different NET_IP_ALIGN values.
> This could explain the behavior. Then what I proposed should wo
Hi George,
On Thu, Apr 8, 2021 at 2:26 PM Sven Van Asbroeck wrote:
>
> George, I will send a patch for you to try shortly. Except if you're
> already ahead :)
Would this work for you? It does for me.
diff --git a/drivers/net/ethernet/microchip/lan743x_main.c
b/drivers/net/ethe
Hi George,
On Thu, Apr 8, 2021 at 3:55 PM George McCollister
wrote:
>
> Works for me too.
Sounds good. I'll post a proper patch soon. Would you be able to
review+test, and perhaps offer your Reviewed-by/Tested-by tags when
everything looks ok?
Hi Heiner,
On Thu, Apr 8, 2021 at 3:06 PM Heiner Kallweit wrote:
>
> A completely unrelated question:
> How about VLAN packets with a 802.1Q tag? Should VLAN_ETH_HLEN be used?
That's a good question. My use-case does not involve 802.1Q though, so
I'm unable to test.
Thank you so much for your s
From: Sven Van Asbroeck
The ethernet frame length is calculated incorrectly. Depending on
the value of RX_HEAD_PADDING, this may result in ethernet frames
that are too short (cut off at the end), or too long (garbage added
to the end).
Fix by calculating the ethernet frame length correctly. For
Hi Andrew,
On Thu, Apr 8, 2021 at 9:02 PM Andrew Lunn wrote:
>
> Adding a Suggested-by: would be good. And it might sometime help
> Johnathan Corbet extract some interesting statistics from the commit
> messages if everybody uses the same format.
Thank you for the suggestion. I'll definitely use
Hi, comments inline.
On Sun, Feb 24, 2019 at 3:36 PM Robert Eshleman wrote:
>
> This patch adds support for the ap3216c ambient light and proximity
> sensor.
>
> Supported features include:
>
> * Illuminance (lux)
> * Proximity (raw)
> * IR (raw)
> * Rising/falling thr
Van Asbroeck
---
drivers/pci/pcie/pme.c | 1 +
1 file changed, 1 insertion(+)
v2:
rebased against Bjorn Helgaas's pcm/pm branch at
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
diff --git a/drivers/pci/pcie/pme.c b/drivers/pci/pcie/pme.c
index efa5b55
On Tue, Apr 16, 2019 at 5:21 PM Enrico Weigelt, metux IT consult
wrote:
>
>
> Yet another question: does each fieldbus_dev instance talk to exactly
> one plc process memory, or can there be many ?
>
> Having separate device nodes per plc process memory seems a good idea
> for finer access control
On Tue, Apr 16, 2019 at 5:21 PM Enrico Weigelt, metux IT consult
wrote:
>
> Yet another question: does each fieldbus_dev instance talk to exactly
> one plc process memory, or can there be many ?
I'm by no means a fieldbus expert, so I had a little chat with one of
the fieldbus
people in the compa
On Mon, Mar 11, 2019 at 3:13 PM Greg KH wrote:
>
> That sounds like a good plan, I'll take that. Want to respin the
> patches with the code in drivers/staging/ and I'll be glad to queue them
> up after 5.1-rc1 is out.
Andreas Farber suggested that the patchset may have more success reaching
its
The work which is scheduled by led_classdev->brightness_set() is
potentially left pending or running until after the driver module
is unloaded.
Fix by using resource-controlled version of INIT_WORK().
Signed-off-by: Sven Van Asbroeck
---
drivers/input/keyboard/cap11xx.c | 6 +-
1 f
lowed by sample fixes for two vulnerable
modules. As far as I can tell, many more modules are vulnerable.
Sven Van Asbroeck (3):
workqueue: Add resource-managed version of INIT_[DELAYED_]WORK()
max17042_battery: fix potential user-after-free on module unload
cap11xx: fix potential user-after
ce-managed version of INIT_[DELAYED_]WORK(). This can be used as
an elegant way to ensure that work is not left pending or running after
its dependencies are released.
Functions introduced in workqueue.h :
- devm_init_work()
- devm_init_delayed_work()
Signed-off-by: Sven Van Asbroeck
---
inc
The work which is scheduled on a POR boot is potentially left
pending or running until after the driver module is unloaded.
Fix by using resource-controlled version of INIT_WORK().
Signed-off-by: Sven Van Asbroeck
---
drivers/power/supply/max17042_battery.c | 5 -
1 file changed, 4
On Tue, Feb 5, 2019 at 3:27 AM Dmitry Torokhov
wrote:
>
> Are there many more instances of this?
Unfortunately I think so.
A simple grep brings up a couple of candidates, but I'm sure there are more:
drivers/regulator/arizona-micsupp.c
drivers/nfc/port100.c
drivers/power/supply/max14656_charger_
On Tue, Feb 5, 2019 at 9:57 AM Kees Cook wrote:
>
>
> Can a Coccinelle script get written to find module-use of the non-devm
> work init?
My thoughts exactly ! But sadly I'm not a Coccinelle expert. I did
look briefly at
its syntax, but I didn't immediately "get" how Cocci could find this class o
Problem:
The cmd_complete_work work could potentially run after resources
are freed in disconnect(). This could cause user-after-free
issues.
Solution:
Reorder disconnect() calls, and explicitly cancel the work
using cancel_work_sync().
Signed-off-by: Sven Van Asbroeck
---
Samuel,
I&#
On Tue, Feb 5, 2019 at 1:43 PM Greg KH wrote:
>
>
> It really should happen when the device is removed (if it is a driver
> that binds to a device.)
Absolutely. That's why I'm advocating adding a devm_init_work(),
which will take care of this automatically.
But it's of course not universally app
On Tue, Feb 5, 2019 at 4:43 PM Dmitry Torokhov
wrote:
>
> OK, great, I'll write up a patch for cap11xx and others if I find them.
>
Possibly also drivers/input/keyboard/lm8323.c
On Thu, Jan 24, 2019 at 3:12 PM Sven Van Asbroeck wrote:
>
> This patch:
> 1. adds a Fieldbus subsystem
> 2. adds support for the HMS Industrial Networks AB Profinet card.
>
Is there any feedback I may address? Any improvements I could make?
Any clarifications?
If not, wh
roduction of
> set_brightness_blocking() we no longer need it.
>
Elegant solution, nice !
I read the patch to verify that the user-after-free is now gone, but
obviously I cannot test,
as I have no cap11xx hardware. For what it's worth:
Reviewed-by: Sven Van Asbroeck
On Wed, Feb 6, 2019 at 12:30 PM Dmitry Torokhov
wrote:
>
> Yeah. But devm irq gave most trouble because we did not have enough
> devm APIs so we often ended up with mixed devm/non-devm usage and that
> is what was causing most of the issues. If we can switch everything to
> devm then devm irq is n
Hi Philipp, thank you so much for looking into this, I really appreciate it !
On Thu, Feb 11, 2021 at 9:32 AM Philipp Zabel wrote:
>
> Another thing that might help to identify who is writing where might be to
> clear the whole OCRAM region and dump it after running only decode or only
> PRE/PRG
From: Sven Van Asbroeck
The buffers in the lan743x driver's receive ring are always 9K,
even when the largest packet that can be received (the mtu) is
much smaller. This performs particularly badly on cpu archs
without dma cache snooping (such as ARM): each received packet
results in a 9K
From: Sven Van Asbroeck
Tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git #
e4b62cf7559f
v1 -> v2:
- Andrew Lunn:
+ always keep to Reverse Christmas Tree.
+ "changing the cache operations to operate on the received length" should
go in its
From: Sven Van Asbroeck
Simulate low-memory in lan743x_rx_allocate_skb(): fail 10
allocations in a row in every 100.
Signed-off-by: Sven Van Asbroeck
---
To: Bryan Whitehead
To: unglinuxdri...@microchip.com
To: "David S. Miller"
To: Jakub Kicinski
Cc: Andrew Lunn
Cc: Alexey D
From: Sven Van Asbroeck
Signed-off-by: Sven Van Asbroeck
---
To: Bryan Whitehead
To: unglinuxdri...@microchip.com
To: "David S. Miller"
To: Jakub Kicinski
Cc: Andrew Lunn
Cc: Alexey Denisov
Cc: Sergej Bauer
Cc: Tim Harvey
Cc: Anders Rønningen
Cc: Hillf Danton
Cc: Christoph H
From: Sven Van Asbroeck
On cpu architectures w/o dma cache snooping, dma_unmap() is a
is a very expensive operation, because its resulting sync
needs to invalidate cpu caches.
Increase efficiency/performance by syncing only those sections
of the lan743x's rx ring buffers that are actual
From: Sven Van Asbroeck
Simulate low-memory in lan743x_rx_trim_skb(): fail one allocation
in every 100.
Signed-off-by: Sven Van Asbroeck
---
To: Bryan Whitehead
To: unglinuxdri...@microchip.com
To: "David S. Miller"
To: Jakub Kicinski
Cc: Andrew Lunn
Cc: Alexey Denisov
Cc: Se
1 - 100 of 526 matches
Mail list logo
