| Age | Commit message (Collapse) | Author |
|---|
|
Also comment on the upstream commits which made them unnecessary.
|
|
|
|
If can327 locks up your machine, but only in very specific situations,
this is probably why. The memory leak fix went too far, and I missed
the call to can327_feed_frame_to_netdev() before a return -ENODATA.
Fixes: 37111be717212b8c7779978c0385393c2d51747d
|
|
|
|
RTR frames don't actually carry data, so bytes sent is 0.
|
|
|
|
This is now handled by common netdev LED events instead:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=6c1e423a3c84953edcf91ff03ab97829b287184a
|
|
This has been gone since a44b237ce7e9 in 2019.
|
|
No idea why this was even there.
|
|
SKBs need to be used or freed before returning, no exceptions.
|
|
|
|
See: https://github.com/norly/elmcan/issues/8
There, a VM was used, and apparently buffers of over 256 bytes were
being piped in.
|
|
If can327_ldisc_rx() is called with a large 'count' because the UART
driver feeds us huge buffers, then the user should have a chance to
know and report this.
In this case, we'll have to increase ELM327_SIZE_RXBUF.
|
|
mailbox_read()'s type signature was changed in 4e9c9484b085 which is
upstream since v5.5.
|
|
While waiting for a <CR> the code would search through prevois received
characters, too. Keep track of what we've already checked to speed this
up.
|
|
|
|
|
|
|
|
TTY drivers don't seem to care, and if they did, we'd likely have
to kmalloc() as before anyway.
|
|
|
|
This is to clarify that this driver is not a product of ELM Electronics.
|
