On Thu 2021-01-14 12:05:21, Heiner Kallweit wrote:
> On 14.01.2021 11:41, claudiu.bez...@microchip.com wrote:
> >
> >
> > On 14.01.2021 12:25, Russell King - ARM Linux admin wrote:
> >>
> >> As I've said, if phylib/PHY driver is not restoring the state of the
> >> PHY on resume from
On Sun, Feb 07, 2021 at 06:15:57PM +0300, Arseny Krasnov wrote:
This adds some logic to current stream enqueue function for SEQPACKET
support:
1) Send record's begin/end marker.
2) Return value from enqueue function is whole record length or error
for SOCK_SEQPACKET.
Signed-off-by: Arseny
Currently, only the 'i' 0x90 ioctl() actually exists and is defined in
'include/uapi/linux/iio/events.h'.
It's the IIO_GET_EVENT_FD_IOCTL, which is used to retrieve and FD for
reading events from an IIO device.
We will want to add more ioct() numbers, so with this change the 'i'
0x90-0x9F space
On Thu, Feb 11, 2021 at 05:40:35PM +0530, Anshuman Khandual wrote:
> On 2/11/21 5:23 PM, Will Deacon wrote:
> > On Fri, Feb 05, 2021 at 06:55:53PM +, Will Deacon wrote:
> >> On Wed, Feb 03, 2021 at 09:20:39AM +0530, Anshuman Khandual wrote:
> >>> On 2/2/21 6:26 PM, David Hildenbrand wrote:
>
This change wraps all buffer attributes into iio_dev_attr objects, and
assigns a reference to the IIO buffer they belong to.
With the addition of multiple IIO buffers per one IIO device, we need a way
to know which IIO buffer is being enabled/disabled/controlled.
We know that all buffer
This change adds a reference to a 'struct iio_buffer' object on the
iio_dev_attr object. This way, we can use the created iio_dev_attr objects
on per-buffer basis (since they're allocated anyway).
A minor downside of this change is that the number of parameters on
__iio_add_chan_devattr() grows
Up until now, the device groups that an IIO device had were limited to 6.
Two of these groups would account for buffer attributes (the buffer/ and
scan_elements/ directories).
Since we want to add multiple buffers per IIO device, this number may not
be enough, when adding a second buffer. So,
We only need a chardev if we need to support buffers and/or events.
With this change, a chardev will be created only if an IIO buffer is
attached OR an event_interface is configured.
Otherwise, no chardev will be created, and the IIO device will get
registered with the 'device_add()' call.
With this change, calling iio_device_attach_buffer() will actually attach
more buffers.
Right now this doesn't do any validation of whether a buffer is attached
twice; maybe that can be added later (if needed). Attaching a buffer more
than once should yield noticeably bad results.
The first
The __iio_buffer_free_sysfs_and_mask() function will be used in
iio_buffer_alloc_sysfs_and_mask() when multiple buffers will be attached to
the IIO device.
This will need to be used to cleanup resources on each buffer, when the
buffers cleanup unwind will occur on the error path.
The move is done
The reference to the IIO buffer object is stored on the attribute object.
So we need to unwind it to obtain it.
Signed-off-by: Alexandru Ardelean
---
drivers/iio/buffer/industrialio-buffer-dmaengine.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
With this change, an ioctl() call is added to open a character device for a
buffer. The ioctl() number is 'i' 0x91, which follows the
IIO_GET_EVENT_FD_IOCTL ioctl.
The ioctl() will return an FD for the requested buffer index. The indexes
are the same from the /sys/iio/devices/iio:deviceX/bufferY
This is a bit of a tidy-up, but also helps with extending the
iioutils_get_type() function a bit, as we don't need to use it outside of
the iio_utils.c file. So, we'll need to update it only in one place.
With this change, the 'unsigned' types are updated to 'unsigned int' in the
Mostly a tidy-up.
But also helps to understand the limits of scope of these functions and
globals.
Signed-off-by: Alexandru Ardelean
---
tools/iio/iio_generic_buffer.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git
The 'dev' variable name usually refers to 'struct device' types. However in
iio_device_alloc() this was used for the 'struct iio_dev' type, which was
sometimes causing minor confusions.
This change renames the variable to 'indio_dev', which is the usual name
used around IIO for 'struct iio_dev'
On Wed, 10 Feb 2021 15:34:24 -0500
Tony Krowiak wrote:
> On 2/10/21 5:53 AM, Cornelia Huck wrote:
> > On Tue, 9 Feb 2021 14:48:30 -0500
> > Tony Krowiak wrote:
> >
> >> This patch fixes a circular locking dependency in the CI introduced by
> >> commit f21916ec4826 ("s390/vfio-ap: clean up
On Thu, Feb 11, 2021 at 06:34:43AM +, Christophe Leroy wrote:
> unrecoverable_exception() is never expected to return, most callers
> have an infiniteloop in case it returns.
>
> Ensure it really never returns by terminating it with a BUG(), and
> declare it __no_return.
>
> It always GCC to
On Thu, Feb 11, 2021 at 08:04:55PM +1000, Nicholas Piggin wrote:
> Excerpts from Christophe Leroy's message of February 11, 2021 5:41 pm:
> > As modern powerpc implement branch folding, that's even more efficient.
Ah, it seems you mean what Arm calls branch folding. Sure, power4
already did
This patchset adds support for two Codec Macro blocks(TX and RX) available in
Qualcomm LPASS (Low Power Audio SubSystem).
There are WSA, VA, TX and RX Macros on LPASS IP, each of the Macro block
has specific connectivity like WSA Macros are intended to connect
to WSA Smart speaker codecs via
This binding is for LPASS has internal codec TX macro which is
for connecting with Soundwire TX codecs like WCD938x.
Signed-off-by: Srinivas Kandagatla
Reviewed-by: Rob Herring
---
.../bindings/sound/qcom,lpass-tx-macro.yaml | 67 +++
1 file changed, 67 insertions(+)
create
Hello Johannes,
在 2021/2/11 上午4:37, Johannes Weiner 写道:
> On Wed, Feb 10, 2021 at 12:06:05PM +0800, Chengming Zhou wrote:
>> Move the reclaim detection from the timer tick to the task state
>> tracking machinery using the recently added ONCPU state. And we
>> also add memstall state changes
This patch adds dapm widgets and routes on this codec
Signed-off-by: Srinivas Kandagatla
---
sound/soc/codecs/lpass-tx-macro.c | 685 ++
1 file changed, 685 insertions(+)
diff --git a/sound/soc/codecs/lpass-tx-macro.c
b/sound/soc/codecs/lpass-tx-macro.c
index
On 11.02.21 13:10, Anshuman Khandual wrote:
On 2/11/21 5:23 PM, Will Deacon wrote:
On Fri, Feb 05, 2021 at 06:55:53PM +, Will Deacon wrote:
On Wed, Feb 03, 2021 at 09:20:39AM +0530, Anshuman Khandual wrote:
On 2/2/21 6:26 PM, David Hildenbrand wrote:
On 02.02.21 13:51, Will Deacon
On 11.02.2021 13:17, Pavel Machek wrote:
> On Thu 2021-01-14 12:05:21, Heiner Kallweit wrote:
>> On 14.01.2021 11:41, claudiu.bez...@microchip.com wrote:
>>>
>>>
>>> On 14.01.2021 12:25, Russell King - ARM Linux admin wrote:
As I've said, if phylib/PHY driver is not restoring the state
On 2/6/21 3:08 PM, Leo Yan wrote:
After support the PID tracing for the kernel in EL1 or EL2, the usage
gets more complicated.
This patch gives description for the PMU formats of contextID configs,
this can help users to understand how to control the knobs for PID
tracing when the kernel is in
On Thu, Feb 11, 2021 at 12:48:54PM +0200, stef...@marvell.com wrote:
> @@ -751,6 +760,10 @@
> #define MVPP2_TX_FIFO_THRESHOLD(kb) \
> ((kb) * 1024 - MVPP2_TX_FIFO_THRESHOLD_MIN)
>
> +/* MSS Flow control */
> +#define FC_QUANTA0x
> +#define FC_CLK_DIVIDER
On Thu, Feb 11, 2021 at 12:48:55PM +0200, stef...@marvell.com wrote:
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 761f745..8b4073c 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++
On Wed, Feb 10, 2021 at 03:13:30PM +0200, Mathias Nyman wrote:
> On 9.2.2021 10.37, Greg Kroah-Hartman wrote:
> > On Fri, Feb 05, 2021 at 02:50:15PM +0800, Kai-Heng Feng wrote:
> >> On Fri, Feb 5, 2021 at 2:45 PM Aaron Ma wrote:
> >>>
> >>>
> >>> On 2/5/21 12:27 PM, Kai-Heng Feng wrote:
>
On Thu, Feb 11, 2021 at 03:23:24PM +0300, Fatih Yildirim wrote:
> On Thu, Feb 11, 2021 at 12:10:44PM +0100, Greg KH wrote:
> > On Thu, Feb 11, 2021 at 01:57:04PM +0300, Fatih YILDIRIM wrote:
> > > On Thu, Feb 11, 2021 at 11:02:51AM +0100, Greg KH wrote:
> > > > On Thu, Feb 11, 2021 at 12:22:39PM
On 2/11/21 1:39 PM, Mark Brown wrote:
> On Thu, Feb 11, 2021 at 10:37:30AM +0100, Michal Simek wrote:
>> st 10. 2. 2021 v 11:10 odesílatel Michal Simek
>> napsal:
>
>>> +description:
>>> + The Xilinx Zynq QSPI controller is used to access multi-bit serial flash
>>> + memory devices.
>
>>
The simplification of mte_get_random_tag() caused the introduction of the
warning below:
In file included from arch/arm64/include/asm/kasan.h:9,
from include/linux/kasan.h:16,
from mm/kasan/common.c:14:
mm/kasan/common.c: In function ‘mte_get_random_tag’:
On Mon 2021-02-08 17:38:29, Richard Fitzgerald wrote:
> On 08/02/2021 15:18, Andy Shevchenko wrote:
> > On Mon, Feb 08, 2021 at 02:01:52PM +, Richard Fitzgerald wrote:
> > > The existing code attempted to handle numbers by doing a strto[u]l(),
> > > ignoring the field width, and then
On Thu, 11 Feb 2021 10:18:56 +0100
David Hildenbrand wrote:
> On 09.02.21 16:43, Claudio Imbrenda wrote:
> > Extend kvm_s390_shadow_fault to return the pointer to the valid leaf
> > DAT table entry, or to the invalid entry.
> >
> > Also return some flags in the lower bits of the address:
> >
On Thu, Feb 11, 2021 at 11:48:41AM +0100, Florian Weimer wrote:
> * Greg Kroah-Hartman:
>
> > I'm announcing the release of the 4.9.256 kernel.
> >
> > This, and the 4.4.256 release are a little bit "different" than normal.
> >
> > This contains only 1 patch, just the version bump from .255 to
On Wed, Feb 10, 2021 at 01:44:35PM +0200, Tudor Ambarus wrote:
> This is a follow-up for:
> commit 3c9ea42802a1 ("clk: Mark fwnodes when their clock provider is
> added/removed")
>
> The above commit updated the deprecated of_clk_add_provider(),
> but missed to update the preferred
Hi Saravana,
On Fri, Feb 5, 2021 at 11:26 PM Saravana Kannan wrote:
> There are a lot of devices/drivers where they never have a struct device
> created for them or the driver initializes the hardware without ever
> binding to the struct device.
>
> This series is intended to avoid any boot
From: Colin Ian King
The left shift of int 32 bit integer constant 1 is evaluated using 32 bit
arithmetic and then assigned to a signed 64 bit integer. In the case where
l2nb is 32 or more this can lead to an overflow. Avoid this by shifting
the value 1LL instead.
Addresses-Coverity:
On Wed, Feb 10, 2021 at 12:13:40PM +0530, Sameer Pujar wrote:
> An endpoint is not a device and it is recommended to use clocks property
> in the device node. Hence reverting the original change.
Please submit patches using subject lines reflecting the style for the
subsystem, this makes it
> -Original Message-
> From: Russell King - ARM Linux admin
> Sent: Thursday, February 11, 2021 2:50 PM
> To: Stefan Chulski
> Cc: net...@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan
> Markman ; linux-kernel@vger.kernel.org;
>
There is a bunch of messy, commented out code. Just delete it.
Suggested-by: Dan Carpenter
Signed-off-by: karthik alapati
---
.../staging/rtl8723bs/hal/rtl8723b_phycfg.c | 40 +--
1 file changed, 2 insertions(+), 38 deletions(-)
diff --git
karthik alapati (2):
staging: rtl8723bs: fix function comments to follow kernel-doc
staging: rtl8723bs: remove obsolete commented out code
.../staging/rtl8723bs/hal/rtl8723b_phycfg.c | 225 ++
1 file changed, 75 insertions(+), 150 deletions(-)
--
2.30.0
> > +/* Configure Rx FIFO Flow control thresholds */ void
> > +mvpp23_rx_fifo_fc_en(struct mvpp2 *priv, int port, bool en) {
> > + int val;
>
> u32 ?
OK.
> > +
> > + val = mvpp2_read(priv, MVPP2_RX_FC_REG(port));
> > +
> > + if (en)
> > + val |= MVPP2_RX_FC_EN;
> > +
On Thu, Feb 11, 2021 at 01:41:49PM +0100, Maximilian Luz wrote:
> The raw message frame length is unaligned and explicitly marked as
> little endian. It should not be accessed without the appropriate
> accessor functions. Fix this.
>
> Note that payload.len already contains the correct length
Hi Hemansh,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
url:
https://github.com/0day-ci/linux/commits/Hemansh-Agnihotri/staging-greybus-Added-do-while-in-multi-statement-macro/20210211-175717
base: https://git.kernel.org/pub/scm
Hi Gustavo,
> Reverting the applied patch because it caused a regression on
> ARC700 platform (32 bits).
[...]
Do you have the previous commit handy to reference here?
Krzysztof
Hi Gustavo,
> In the previous implementation the driver assumes that only existed 2
> memory spaces that would be equal distributed amount the write/read
> channels.
What do you think about:
In the previous implementation the driver assumed that there existed
only two memory spaces that
On Thu 11-02-21 12:57:17, Matthew Wilcox wrote:
> On Thu, Feb 11, 2021 at 01:34:48PM +0100, Michal Hocko wrote:
> > On Thu 11-02-21 13:10:20, Jan Kara wrote:
> > > On Thu 11-02-21 12:28:48, Dmitry Vyukov wrote:
> > > > On Thu, Feb 11, 2021 at 12:22 PM Dmitry Vyukov
> > > > wrote:
> > > > >
> > >
Hi Gustavo,
> Detected by CoverityScan CID 16555 ("Dereference null return")
[...]
We can use the "Addresses-Coverity:" here, as it seems to become
a canonical thing for Coverity reports. It would also be nice to
briefly mention what the issues was, if possible.
Krzysztof
On 11/02/21 02:56, Sean Christopherson wrote:
+ pta->gpa = (vm_get_max_gfn(vm) - guest_num_pages) *
pta->guest_page_size;
+ pta->gpa &= ~(pta->host_page_size - 1);
Also not related to this patch, but another case for align.
if (backing_src == VM_MEM_SRC_ANONYMOUS_THP ||
On Thu 11-02-21 10:53:51, Alexander Lochmann wrote:
>
>
> On 11.02.21 10:30, Jan Kara wrote:
> > >*/
> > > unsigned long t_log_start;
> > > - /* Number of buffers on the t_buffers list [j_list_lock] */
> > > + /* Number of buffers on the t_buffers list
On Thu, Feb 11, 2021 at 2:38 PM Alexandru Ardelean
wrote:
>
> Following a recent update to the IIO buffer infrastructure, this change
> adds a basic example on how to access an IIO buffer via the new mmap()
> interface.
>
> The ioctl() for the high-speed mode needs to be enabled right from the
>
On Thu, 11 Feb 2021 10:05:16 +0100
Krzysztof Kozlowski wrote:
> On Thu, Feb 11, 2021 at 09:03:27AM +, Lee Jones wrote:
> > On Wed, 10 Feb 2021, Krzysztof Kozlowski wrote:
> >
> > > On Wed, Feb 10, 2021 at 11:33:49AM -0600, Dan Murphy wrote:
> > > > Krzysztof
> > > >
> > > > On 2/10/21
Some tweaks in v5, and this time I merged all the changelog histories into
this final one.
Changelog v4 -> v5:
*
https://lore.kernel.org/linux-iio/20210210100823.46780-1-alexandru.ardel...@analog.com/T/#t
* patch 'iio: buffer: add ioctl() to support opening extra buffers for IIO
device'
With this change, we create a new directory for the IIO device called
buffer0, under which both the old buffer/ and scan_elements/ are stored.
This is done to simplify the addition of multiple IIO buffers per IIO
device. Otherwise we would need to add a bufferX/ and scan_elementsX/
directory for
If we want to merge the attributes of the buffer/ and scan_elements/
directories, we'll need to count all attributes first, then (depending on
the attribute group) either allocate 2 attribute groups, or a single one.
Historically an IIO buffer was described by 2 subdirectories under
Oddly enough the noop function is an int-return. This one seems to be void.
This change converts it to int, because we want to change how groups are
registered. With that change this function could error out with -ENOMEM.
Signed-off-by: Alexandru Ardelean
---
drivers/iio/iio_core_trigger.h
In order to keep backwards compatibility with the current chardev
mechanism, and in order to add support for multiple buffers per IIO device,
we need to pass both the IIO device & IIO buffer to the chardev.
This is particularly needed for the iio_buffer_read_outer() function, where
we need to
This change makes use of the new IIO buffer API to read data from an IIO
buffer.
It doesn't read the /sys/bus/iio/devices/iio:deviceX/scan_elements dir
anymore, it reads /sys/bus/iio/devices/iio:deviceX/bufferY, where all the
scan_elements have been merged together with the old/classical buffer
On Thu, Feb 11, 2021 at 12:10:44PM +0100, Greg KH wrote:
> On Thu, Feb 11, 2021 at 01:57:04PM +0300, Fatih YILDIRIM wrote:
> > On Thu, Feb 11, 2021 at 11:02:51AM +0100, Greg KH wrote:
> > > On Thu, Feb 11, 2021 at 12:22:39PM +0300, Fatih Yildirim wrote:
> > > > Fix for checkpatch.pl warning:
> > >
This binding is for LPASS has internal codec RX macro which is
for connecting with SoundWire RX codecs like WCD938x.
Signed-off-by: Srinivas Kandagatla
Reviewed-by: Rob Herring
---
.../bindings/sound/qcom,lpass-rx-macro.yaml | 62 +++
1 file changed, 62 insertions(+)
create
On Sun, Feb 07, 2021 at 06:16:12PM +0300, Arseny Krasnov wrote:
This does rest of SOCK_SEQPACKET support:
1) Adds socket ops for SEQPACKET type.
2) Allows to create socket with SEQPACKET type.
Signed-off-by: Arseny Krasnov
---
net/vmw_vsock/af_vsock.c | 37 -
Le 11/02/2021 à 12:49, Segher Boessenkool a écrit :
On Thu, Feb 11, 2021 at 07:41:52AM +, Christophe Leroy wrote:
powerpc BUG_ON() is based on using twnei or tdnei instruction,
which obliges gcc to format the condition into a 0 or 1 value
in a register.
Huh? Why is that?
Will it work
Qualcomm LPASS (Low Power Audio SubSystem) has internal codec
TX macro block which is used for connecting with external
Soundwire TX Codecs like WCD938x.
This patch adds support to the codec part of the TX Macro block
Signed-off-by: Srinivas Kandagatla
---
sound/soc/codecs/Kconfig |
LPASS RX Codec Macro is available in Qualcomm LPASS (Low Power Audio SubSystem).
This is used for connecting with SoundWire devices like WCD938x Codecs to
provide
headphone/ear/lineout functionality.
Signed-off-by: Srinivas Kandagatla
---
sound/soc/codecs/Kconfig |5 +
On Thu 11-02-21 13:20:08, Mike Rapoport wrote:
[...]
> Sealing is anyway controlled via fcntl() and I don't think
> MFD_ALLOW_SEALING makes much sense for the secretmem because it is there to
> prevent rogue file sealing in tmpfs/hugetlbfs.
This doesn't really match my understanding. The primary
This patch adds iir widgets and mixers on this codec
Signed-off-by: Srinivas Kandagatla
---
sound/soc/codecs/lpass-rx-macro.c | 264 ++
1 file changed, 264 insertions(+)
diff --git a/sound/soc/codecs/lpass-rx-macro.c
b/sound/soc/codecs/lpass-rx-macro.c
index
This patch adds dapm widgets and routes on this codec
Signed-off-by: Srinivas Kandagatla
---
sound/soc/codecs/lpass-rx-macro.c | 1341 +
1 file changed, 1341 insertions(+)
diff --git a/sound/soc/codecs/lpass-rx-macro.c
b/sound/soc/codecs/lpass-rx-macro.c
index
Following a recent update to the IIO buffer infrastructure, this change
adds a basic example on how to access an IIO buffer via the new mmap()
interface.
The ioctl() for the high-speed mode needs to be enabled right from the
start, before setting any parameters via sysfs (length, enable, etc), to
On Thu, Feb 11, 2021 at 01:42:43PM +0200, Leon Romanovsky wrote:
> On Thu, Feb 11, 2021 at 10:08:38AM +0100, Gustavo Pimentel wrote:
> > Add Synopsys DesignWare xData IP driver. This driver enables/disables
> > the PCI traffic generator module pertain to the Synopsys DesignWare
> > prototype.
> >
From: Lars-Peter Clausen
Add support for the new mmap interface to IIO DMA buffer. This interface
allows to directly map the backing memory of a block to userspace. This is
especially advantageous for high-speed devices where the extra copy from
kernel space to userspace of the data incurs a
From: Lars-Peter Clausen
Add the necessary infrastructure to the IIO core to support an mmap based
interface to access the capture data.
The advantage of the mmap based interface compared to the read() based
interface is that it avoids an extra copy of the data between kernel and
userspace.
This is basically Lars' work adapted from branch:
https://github.com/larsclausen/linux/commits/iio-high-speed-5.10
[hopefully i got the stuff correctly from that branch]
What is different, is that this one is adapted on top of the multibuffer
support (currently at v5) discussed here:
Extend regulator notification support
This is an RFC series for getting feedback on extending the regulator
notification and error flag support. Initial discussion on the topic can
be found here:
https://lore.kernel.org/lkml/6046836e22b8252983f08d5621c35ececb97820d.ca...@fi.rohmeurope.com/
This
Support specifying protection/error/warning limits for regulator
over current, over temperature and over/under voltage.
Most of the PMICs support only "protection" feature but few
setups do also support error/warning level indications.
On many ICs most of the protection limits can't actually be
Hi!
> If the debug_never_hash_pointers command line parameter is set, then
Can we make this something shorter? Clearly you don't want people
placing this in their grub config, so they'll be most likely typing
this a lot...
debug_pointers or debug_ptrs would be better.
Thanks,
Add 'warning' level events and error flags to regulator core.
Current regulator core notifications are used to inform consumers
about errors where HW is misbehaving in such way it is assumed to
be broken/unrecoverable.
There are PMICs which are designed for system(s) that may have use
for
On Thu 11-02-21 13:10:20, Jan Kara wrote:
> On Thu 11-02-21 12:28:48, Dmitry Vyukov wrote:
> > On Thu, Feb 11, 2021 at 12:22 PM Dmitry Vyukov wrote:
> > >
> > > On Thu, Feb 11, 2021 at 11:49 AM Jan Kara wrote:
> > > >
> > > > Hello,
> > > >
> > > > added mm guys to CC.
> > > >
> > > > On Wed
Provide helper function for IC's implementing regulator notifications
when an IRQ fires. The helper also works for IRQs which can not be acked.
Helper can be set to disable the IRQ at handler and then re-enabling it
on delayed work later. The helper also adds regulator_get_error_flags()
errors in
Add DT property parsing code and setting callback for regulator over/under
voltage, over-current and temperature error limits.
Signed-off-by: Matti Vaittinen
---
drivers/regulator/core.c | 122 +-
drivers/regulator/of_regulator.c | 58 ++
On Thu, Feb 11, 2021 at 03:27:38AM +0100, Michał Mirosław wrote:
> On Wed, Feb 10, 2021 at 07:23:04PM +, Michal Rostecki wrote:
> > On Wed, Feb 10, 2021 at 01:58:15PM +0100, Michał Mirosław wrote:
> > > On Wed, Feb 10, 2021 at 12:29:25PM +, Michal Rostecki wrote:
> > > > On Wed, Feb 10,
On 2/6/21 3:08 PM, Leo Yan wrote:
This patch adds helper function cs_etm__get_pid_fmt(), by passing
parameter "traceID", it returns the PID format.
Signed-off-by: Leo Yan
Reviewed-by: Suzuki K Poulose
Driver name was changed in MFD cell:
https://lore.kernel.org/lkml/560b9748094392493ebf7af11b6cc558776c4fd5.1613031055.git.matti.vaitti...@fi.rohmeurope.com/
Fix the ID table to match this.
Signed-off-by: Matti Vaittinen
---
drivers/regulator/bd9576-regulator.c | 4 ++--
1 file changed, 2
BD9573 and BD9576 support set of "protection" interrupts for "fatal"
issues. Those lead to SOC reset as PMIC shuts the power outputs. Thus
there is no relevant IRQ handling for them.
Few "detection" interrupts were added to the BD9576 with the idea that
SOC could take some recovery-action before
Considering the following testcase:
int
foo(int a, int b)
{
for (unsigned i = 0; i < 10; i++)
a += b;
return a;
}
int main()
{
foo (3, 4);
return 0;
}
perf annotate displays:
86.52 │40055e: → ja 40056c
13.37 │400560: mov -0x18(%rbp),%eax
│400563: add
BD9576MUF provides over-current protection and detection. Current is
measured as voltage loss over external FET. Allow specifying FET's on
resistance so current monitoring limits can be converted to voltages.
Signed-off-by: Matti Vaittinen
---
On Thu, Feb 11, 2021 at 10:37:30AM +0100, Michal Simek wrote:
> st 10. 2. 2021 v 11:10 odesílatel Michal Simek
> napsal:
> > +description:
> > + The Xilinx Zynq QSPI controller is used to access multi-bit serial flash
> > + memory devices.
> Applied.
Doesn't really matter here but I would
The raw message frame length is unaligned and explicitly marked as
little endian. It should not be accessed without the appropriate
accessor functions. Fix this.
Note that payload.len already contains the correct length after parsing
via sshp_parse_frame(), so we can simply use that instead.
On Thu 11-02-21 14:49:43, Dan Carpenter wrote:
> On Thu, Feb 11, 2021 at 11:50:38AM +0100, 'Michal Hocko' via syzkaller-bugs
> wrote:
> > On Thu 11-02-21 11:22:25, Jan Kara wrote:
> > > On Thu 11-02-21 12:07:29, Hillf Danton wrote:
> >
> > I haven't received Hillf's email.
> >
> > [...]
> > > >
On Thu, Feb 11, 2021 at 01:26:12PM +0100, Christophe Leroy wrote:
> >What PowerPC cpus implement branch folding? I know none.
>
> Extract from powerpc mpc8323 reference manual:
> — Zero-cycle branch capability (branch folding)
Yeah, this is not what is traditionally called branch folding
On Thursday 11 February 2021 11:50:26 CET Muhammad Usama Anjum wrote:
>
> In this particular case, the struct element is already flexible struct.
> Thus struct element ie[] is ambiguous inside another struct. The members
> of struct element ie aren't being accessed in code anywhere. The data of
>
On Thu, Feb 11, 2021 at 12:48:56PM +0200, stef...@marvell.com wrote:
> +static void mvpp2_cm3_write(struct mvpp2 *priv, u32 offset, u32 data)
> +{
> + writel(data, priv->cm3_base + offset);
> +}
> +
> +static u32 mvpp2_cm3_read(struct mvpp2 *priv, u32 offset)
> +{
> + return
Em Mon, Feb 08, 2021 at 09:08:49PM +0100, Jiri Olsa escreveu:
> +__maybe_unused
> +static int send_cmd(struct daemon *daemon, union cmd *cmd)
> +{
> + int ret = -1, fd;
> + char *line = NULL;
> + size_t len = 0;
> + ssize_t nread;
> + FILE *in = NULL;
> +
> + if
Hi Gustavo,
[...]
> + * Typically this function will be called by the pci driver, which passes
It would be "PCI" here.
> + * through argument the 'struct pci_dev *' already pointing for the device
> + * config space that is associated with the vendor and device ID which will
> + * know which ID
On Wed, Feb 10, 2021 at 10:03:31PM -0500, min.li...@renesas.com wrote:
> From: Min Li
>
> This driver supports 1588 related functions of ClockMatrix(TM)
> and 82P33xxx families of timing and synchronization devices. The
> supported functons are:
>
> - set combomode
> - get dpll's state
> - get
Em Thu, Feb 11, 2021 at 11:11:19AM +0100, Peter Zijlstra escreveu:
> On Wed, Feb 10, 2021 at 03:42:19PM -0800, Kees Cook wrote:
> > As started by commit 05a5f51ca566 ("Documentation: Replace lkml.org
> > links with lore"), replace lkml.org links with lore to better use a
> > single source that's
On Thu, Feb 11, 2021 at 01:34:48PM +0100, Michal Hocko wrote:
> On Thu 11-02-21 13:10:20, Jan Kara wrote:
> > On Thu 11-02-21 12:28:48, Dmitry Vyukov wrote:
> > > On Thu, Feb 11, 2021 at 12:22 PM Dmitry Vyukov wrote:
> > > >
> > > > On Thu, Feb 11, 2021 at 11:49 AM Jan Kara wrote:
> > > > >
> >
On Thu, Feb 11, 2021 at 12:49:01PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> This patch fix GMAC TX flow control autoneg.
> Flow control autoneg wrongly were disabled with enabled TX
> flow control.
>
> Signed-off-by: Stefan Chulski
> Acked-by: Marcin Wojtas
Should this
On Wed, 10 Feb 2021 16:30:23 +
Alexander Lobakin wrote:
> Instead of just bulk-flushing skbuff_heads queued up through
> napi_consume_skb() or __kfree_skb_defer(), try to reuse them
> on allocation path.
Maybe you are already aware of this dynamics, but high speed NICs will
usually run the
On Thu, Feb 11, 2021 at 12:49:00PM +0200, stef...@marvell.com wrote:
> +/* Configure Rx FIFO Flow control thresholds */
> +void mvpp23_rx_fifo_fc_en(struct mvpp2 *priv, int port, bool en)
> +{
> + int val;
u32 ?
> +
> + val = mvpp2_read(priv, MVPP2_RX_FC_REG(port));
> +
> +
Hi Gustavo,
> + /*
> + * Tries to find if exists a PCIe Vendor-Specific Extended Capability
> + * for the DMA, if exists one, then reconfigures with the new data
[...]
What about "if one exists" and "then reconfigures it". Missing period
at the end of the sentence.
Krzysztof
1 - 100 of 1369 matches
Mail list logo
