Hey Tomasz & Andrey,
On Fri, 8 Jan 2021 at 11:46, Andrey Konovalov
wrote:
>
> Hi Robert and Tomasz,
>
> On 08.01.2021 12:49, Tomasz Figa wrote:
> > Hi Robert,
> >
> > On Thu, Jan 7, 2021 at 11:21 PM Robert Foss wrote:
> >>
> >> The Bayer GRBG10 mode used for earlier modes 3280x2460 and
> >>
On Fri, 8 Jan 2021 at 12:28, Andrey Konovalov
wrote:
>
> Hi Robert,
>
> On 08.01.2021 13:46, Andrey Konovalov wrote:
> > Hi Robert and Tomasz,
> >
> > On 08.01.2021 12:49, Tomasz Figa wrote:
> >> Hi Robert,
> >>
> >> On Thu, Jan 7, 2021 at 11:21 PM Robert Foss wrote:
> >>>
> >>> The Bayer GRBG10
On Fri, 8 Jan 2021, Filipe Laíns wrote:
> > > -static int hidpp20_query_battery_info(struct hidpp_device *hidpp)
> > > +static int hidpp20_query_battery_info_1000(struct hidpp_device *hidpp)
> >
> > That '_1000' suffix looks strange to me, as it's not completely obvious
> > just from looking at
On Fri, Jan 08, 2021 at 01:31:56PM +0100, Borislav Petkov wrote:
> On Thu, Jan 07, 2021 at 09:08:44AM -0800, Paul E. McKenney wrote:
> > Some information is usually better than none. And I bet that failing
> > hardware is capable of all sorts of tricks at all sorts of levels. ;-)
>
> Tell me
On Fri, 2021-01-08 at 14:44 +0100, Jiri Kosina wrote:
> On Mon, 4 Jan 2021, la...@archlinux.org wrote:
>
> > From: Filipe Laíns
> >
> > This new feature present in new devices replaces the old Battery Level
> > Status (0x1000) feature. It keeps essentially the same information for
> > levels
On Mon, 4 Jan 2021, Filipe Laíns wrote:
> Tested. The device gets correctly exported to userspace and I can see
> mouse and keyboard events.
>
> Signed-off-by: Filipe Laíns
Applied to hid.git#for-5.11/upstream-fixes.
--
Jiri Kosina
SUSE Labs
On 8.1.2021 8.11, Chunfeng Yun wrote:
> On Thu, 2021-01-07 at 13:09 +0200, Mathias Nyman wrote:
>> On 29.12.2020 8.24, Ikjoon Jang wrote:
>>> xhci-mtk has hooks on add_endpoint() and drop_endpoint() from xhci
>>> to handle its own sw bandwidth managements and stores bandwidth data
>>> into
Hi Marjan,
On 1/8/21 10:32 AM, Marjan Pascolo wrote:
Hi,
please don't top post, answer in-line as we do, and please use
plain-test instead of HTML. These are the standards in Mailing Lists(ML).
Quote "
I'm not really sure why we need the first patch of this series here?
That patch only
On Fri, Jan 08, 2021 at 06:41:05PM +0800, Tian Tao wrote:
> Based on the drm_connector_mode_valid, if the hibmc implementation
> of mode_valid only returns MODE_OK, then we can not implement the
s/can not/need not/
> mode_valid function.
>
> Signed-off-by: Tian Tao
Reviewed-by: Daniel Vetter
On Thu, Jan 07, 2021 at 09:28:07AM -0500, Thara Gopinath wrote:
> Hi Christian,
>
> On 1/6/21 3:16 PM, Cristian Marussi wrote:
> > Having added the support for SCMI protocols as modules in order to let
> > vendors extend the SCMI core with their own additions it seems odd to
> > then force SCMI
On Thu, Jan 07, 2021 at 02:03:47PM -0800, Siddharth Gupta wrote:
> On 1/6/2021 2:33 AM, Greg KH wrote:
> > > > > Since the binary attributes don't support splice_{read,write}
> > > > > functions the
> > > > > calls to splice_{read,write} used the default kernel_{read,write}
> > > > > functions.
On Fri, Jan 08, 2021 at 02:41:19PM +0100, Vincent Guittot wrote:
> > 1. avg_scan_cost is now based on the average scan cost of a rq but
> >avg_idle is still scaled to the domain size. This is a bit problematic
> >because it's comparing scan cost of a single rq with the estimated
> >
Hi Linus,
Please pull these IOMMU fixes for -rc3. It's mainly all Intel VT-D stuff,
but there are some fixes for AMD and ARM as well. We've also got the
revert I promised during the merge window, which removes a temporary
hack to accomodate i915 while we transitioned the Intel IOMMU driver
over
Hi Trond,
On 08/01/2021 12:58, Trond Myklebust wrote:
> On Fri, 2021-01-08 at 12:41 +0100, Kurt Garloff wrote:
>> Hi Neil, Anna, Trond,
>>
>> compiling a kernel, I suddenly started getting errors from objtool
>> orc.
>> (This first occurs on init/main.o.)
>>
>> I looked at all kind of things,
On Fri, Jan 1, 2021 at 12:39 PM Adam Ford wrote:
> The RZ/G2 series contain the SPI Multi I/O Bus Controller (RPC-IF).
> Add the nodes, but make them disabled by default.
>
> Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-devel for v5.12.
On 08/01/2021 14:41, Michal Hocko wrote:
> On Wed 06-01-21 16:20:15, Milan Broz wrote:
>> Hi,
>>
>> we use mlockall(MCL_CURRENT | MCL_FUTURE) / munlockall() in cryptsetup code
>> and someone tried to use it with hardened memory allocator library.
>>
>> Execution time was increased to extreme
On 08/01/21 09:11, Vincent Guittot wrote:
> On Thu, 7 Jan 2021 at 18:40, Valentin Schneider
> wrote:
>>
>> On 07/01/21 13:20, Vincent Guittot wrote:
>> > On Thu, 7 Jan 2021 at 12:26, Valentin Schneider
>> > wrote:
>> >> > @@ -9499,13 +9499,32 @@ asym_active_balance(struct lb_env *env)
>> >> > }
On Fri, Jan 08, 2021 at 02:22:00PM +, Filipe Manana wrote:
> On Thu, Jan 7, 2021 at 1:13 PM syzbot
> wrote:
> >
> > syzbot suspects this issue was fixed by commit:
> >
> > commit f30bed83426c5cb9fce6cabb3f7cc5a9d5428fcc
> > Author: Filipe Manana
> > Date: Fri Nov 13 11:24:17 2020 +
> >
On Fri, Jan 08, 2021 at 02:22:00PM +, Filipe Manana wrote:
> On Thu, Jan 7, 2021 at 1:13 PM syzbot
> wrote:
> >
> > syzbot suspects this issue was fixed by commit:
> >
> > commit f30bed83426c5cb9fce6cabb3f7cc5a9d5428fcc
> > Author: Filipe Manana
> > Date: Fri Nov 13 11:24:17 2020 +
> >
Hi,
On 1/8/21 10:23 AM, Maxime Ripard wrote:
Hi,
Thanks for those patches
On Thu, Jan 07, 2021 at 03:30:32AM +0100, Giulio Benetti wrote:
From: Giulio Benetti
It turned out(Maxime suggestion) that bit 26 of SUN4I_TCON0_IO_POL_REG is
dedicated to invert DCLK polarity and this makes thing
Hi Will,
On 2021/1/8 22:09, Will Deacon wrote:
Hi Lu,
On Fri, Jan 08, 2021 at 07:52:47AM +0800, Lu Baolu wrote:
On 2021/1/6 9:09, Lu Baolu wrote:
On 2021/1/6 3:03, Will Deacon wrote:
On Thu, Dec 31, 2020 at 08:53:20AM +0800, Lu Baolu wrote:
@@ -170,6 +172,22 @@ static void
On Sat, Jan 2, 2021 at 12:54 PM Adam Ford wrote:
> The RZ/G2 Series has the RPC-IF interface.
> Update bindings to support: r8a774a1, r8a774b1, r8a774c0, and r8a774e1
>
> Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert
Replace the OCSD_INSTR switch statement with an if to
fix compilation error about unhandled values and avoid
this issue again in the future.
Add new OCSD_GEN_TRC_ELEM_SYNC_MARKER and
OCSD_GEN_TRC_ELEM_MEMTRANS enum values to fix unhandled
value compilation error. Currently they are ignored.
On Mon, Dec 28, 2020 at 10:32 PM Adam Ford wrote:
> The bindings have been updated to support two clocks, but the
> original clock now requires the name fck. Add a clock-names
> list in the device tree with fck in it.
>
> Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
i.e. will
Hi Adam,
On Fri, Jan 8, 2021 at 3:11 PM Geert Uytterhoeven wrote:
> On Mon, Dec 28, 2020 at 10:32 PM Adam Ford wrote:
> > The AVB driver assumes there is an external clock, but it could
> > be driven by an external clock. In order to enable a programmable
> > clock, it needs to be added to the
On Thu, Jan 7, 2021 at 1:13 PM syzbot
wrote:
>
> syzbot suspects this issue was fixed by commit:
>
> commit f30bed83426c5cb9fce6cabb3f7cc5a9d5428fcc
> Author: Filipe Manana
> Date: Fri Nov 13 11:24:17 2020 +
>
> btrfs: remove unnecessary attempt to drop extent maps after adding inline
On Fri, 08 Jan 2021, Joe Perches wrote:
> On Fri, 2021-01-08 at 10:53 +, Lee Jones wrote:
> > On Fri, 08 Jan 2021, Zheng Yongjun wrote:
> >
> > You're still not using the correct subject format.
> >
> > It should be:
> >
> > "mfd: : Description starting with an uppercase char"
>
> IMO:
From: Chen-Yu Tsai
The custom regulatory ruleset in the rtl8723bs driver lists an incorrect
number of rules: one too many. This results in an out-of-bounds access,
as detected by KASAN. This was possible thanks to the newly added support
for KASAN on ARMv7.
Fix this by filling in the correct
Hi Mathieu,
Please hold on with this series, I will update the series, fixing the
issues you have spotted and some additional patches to prevent accesses
to all the system registers that may not be available via system instructions.
Apologies for the inconvenience
Kind regards
Suzuki
On
On Mon, Dec 28, 2020 at 10:32 PM Adam Ford wrote:
> The bindings have been updated to support two clocks, but the
> original clock now requires the name fck. Add a clock-names
> list in the device tree with fck in it.
>
> Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
i.e. will
Hi Adam,
On Tue, Jan 5, 2021 at 1:53 PM Adam Ford wrote:
> On Mon, Jan 4, 2021 at 4:41 AM Geert Uytterhoeven
> wrote:
> > On Mon, Dec 28, 2020 at 10:32 PM Adam Ford wrote:
> > > The bindings have been updated to support two clocks, but the
> > > original clock now requires the name fck to
allmodconfig
powerpc allnoconfig
x86_64 randconfig-a004-20210108
x86_64 randconfig-a006-20210108
x86_64 randconfig-a001-20210108
x86_64 randconfig-a002-20210108
x86_64 randconfig
On Mon, Dec 28, 2020 at 10:32 PM Adam Ford wrote:
> The AVB driver assumes there is an external clock, but it could
> be driven by an external clock. In order to enable a programmable
> clock, it needs to be added to the clocks list and enabled in the
> driver. Since there currently only one
On Mon, Dec 28, 2020 at 9:22 PM Adam Ford wrote:
> Per the reference manal for the RZ/G Series, 2nd Generation,
manual
> the RZ/G2M, RZ/G2N, and RZ/G2H have a bit that can be set to
> choose between a crystal oscillator and an external oscillator.
>
> Because only boards that need this should
On Fri, Jan 08, 2021 at 08:58:38AM +0100, Jiri Slaby wrote:
> On 07. 01. 21, 19:16, Cristian Ciocaltea wrote:
> > Hi Greg,
> >
> > Thank you for the review!
> >
> > On Thu, Jan 07, 2021 at 04:20:55PM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Jan 05, 2021 at 07:02:02PM +0200, Cristian
Hi Lu,
On Fri, Jan 08, 2021 at 07:52:47AM +0800, Lu Baolu wrote:
> On 2021/1/6 9:09, Lu Baolu wrote:
> > On 2021/1/6 3:03, Will Deacon wrote:
> > > On Thu, Dec 31, 2020 at 08:53:20AM +0800, Lu Baolu wrote:
> > > > @@ -170,6 +172,22 @@ static void intel_flush_svm_range_dev
> > > > (struct
On Fri, Jan 08, 2021 at 10:17:25AM +0100, Dmitry Vyukov wrote:
> On Thu, Jan 7, 2021 at 2:11 PM syzbot
> wrote:
> >
> > syzbot suspects this issue was fixed by commit:
> >
> > commit f30bed83426c5cb9fce6cabb3f7cc5a9d5428fcc
> > Author: Filipe Manana
> > Date: Fri Nov 13 11:24:17 2020 +
> >
Hi Rob, Grygorii,
On 27/11/20 7:53 pm, Nishanth Menon wrote:
> On 09:46-20201124, Sekhar Nori wrote:
>> On 24/11/20 6:51 AM, Nishanth Menon wrote:
>>> On 09:45-20201123, Sekhar Nori wrote:
>> The main reason I commented - is hope to get some clarification from DT
>> maintainers.
>>
On Fri, Jan 08, 2021 at 09:52:22PM +0800, zhenwei pi wrote:
> According to pvpanic spec:
> https://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/specs/pvpanic.txt
>
> The guest should determine pvpanic capability by RDPT, so initialize
> capability during device probing. There is no need to
On Fri, Jan 08, 2021 at 09:52:23PM +0800, zhenwei pi wrote:
> Suggested by Paolo, add a module parameter that can be used to limit
> which capabilities the driver uses.
>
> Finally, the pvpanic guest driver works by the limitation of both
> device capability and user setting.
>
> Signed-off-by:
On 2021-01-08 19:09, Konrad Dybcio wrote:
Konrad, can you please test this below change without your change?
This brings no difference, a BUG still happens. We're still calling
to_a6xx_gpu on ANY device that's probed! Too bad it won't turn my A330
into an A640..
Also, relying on disabling
On Mon, Dec 28, 2020 at 9:22 PM Adam Ford wrote:
> The datasheet for the RZ/G2 Series show the bit for choosing between a crystal
> oscillator and an external oscillator is present. Add the bindings for
> r8a774a1 (RZ/G2M), r8a774b1 (RZ/G2N), and r8a774e1 (RZ/G2H)
>
> Signed-off-by: Adam Ford
Hi Adam,
On Thu, Dec 24, 2020 at 6:05 PM Adam Ford wrote:
> The eMMC can run at hs400 and the WiFi chip can run at sdr104.
> Set the respective flags to push the sdhi faster.
>
> Signed-off-by: Adam Ford
Thanks for your patch!
> --- a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
> +++
The following patches fix tegra-hda on legacy tegra devices.
Two issues were discovered preventing tegra-hda from functioning:
-The hda clocks on tegra30 were assigned to clk_m and running at too low
of a rate to function.
-The tegra-hda encounters an input/output error when opening a stream.
Current implementation defaults the hda clocks to clk_m. This causes hda
to run too slow to operate correctly. Fix this by defaulting to pll_p and
setting the frequency to the correct rate.
This matches upstream t124 and downstream t30.
Acked-by: Jon Hunter
Tested-by: Ion Agorria
Currently hda on tegra30 fails to open a stream with an input/output error.
For example:
speaker-test -Dhw:0,3 -c 2
speaker-test 1.2.2
Playback device is hw:0,3
Stream parameters are 48000Hz, S16_LE, 2 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size
On Thu, Dec 24, 2020 at 6:05 PM Adam Ford wrote:
> eacon EmebeddedWorks is introducing a new kit based on the
> RZ/G2H SoC from Renesas.
>
> The SOM supports eMMC, WiFi and Bluetooth, along with a Cat-M1
> cellular radio.
>
> The Baseboard has Ethernet, USB, HDMI, stereo audio in and out,
> along
allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a004-20210108
x86_64 randconfig-a006-20210108
x86_64 randconfig-a001-20210108
x86_64 randconfig-a002-20210108
x86_64
On 1/8/21 12:36 AM, Rob Clark wrote:
> On Thu, Jan 7, 2021 at 9:20 AM Rob Clark wrote:
>>
>> On Sat, Jan 2, 2021 at 12:26 PM Iskren Chernev
>> wrote:
>>>
>>> The msm_gem_get_iova should be guarded with gpu != NULL and not aspace
>>> != NULL, because aspace is NULL when using vram carveout.
On Fri, Jan 08, 2021 at 05:24:13PM +0800, Zheng Yongjun wrote:
> Replace a comma between expression statements by a semicolon.
Pushed to my review and testing queue, thanks!
> Signed-off-by: Zheng Yongjun
> ---
> drivers/gpio/gpio-wcove.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Hi Adam,
On Thu, Dec 24, 2020 at 6:05 PM Adam Ford wrote:
> Beacon EmebeddedWorks is introducing a new kit based on the
> RZ/G2N SoC from Renesas.
>
> The SOM supports eMMC, WiFi and Bluetooth, along with a Cat-M1
> cellular radio.
>
> The Baseboard has Ethernet, USB, HDMI, stereo audio in and
According to pvpanic spec:
https://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/specs/pvpanic.txt
The guest should determine pvpanic capability by RDPT, so initialize
capability during device probing. There is no need to register panic
notifier callback function if no events supported.
Before
v2 -> v3:
Seperate the function to 2 parts:
1, use sysfs to expose device capability.
2, add a module parameter to set limitation by user.
v1 -> v2:
Remove device info log, use module parameter to expose capability.
v1:
The guest sides determines pvpanic capability by RDPT, before
Suggested by Paolo, add a module parameter that can be used to limit
which capabilities the driver uses.
Finally, the pvpanic guest driver works by the limitation of both
device capability and user setting.
Signed-off-by: zhenwei pi
---
drivers/misc/pvpanic.c | 6 +-
1 file changed, 5
On Wed, 16 Dec 2020, Randy Dunlap wrote:
> Prevent invalid (0, 0) inputs to hid-core's snto32() function.
>
> Maybe it is just the dummy device here that is causing this, but
> there are hundreds of calls to snto32(0, 0). Having n (bits count)
> of 0 is causing the current UBSAN trap with a
On 1/6/21 2:17 AM, paul...@kernel.org wrote:
> From: "Paul E. McKenney"
>
> There are kernel facilities such as per-CPU reference counts that give
> error messages in generic handlers or callbacks, whose messages are
> unenlightening. In the case of per-CPU reference-count underflow, this
> is
On Fri, Jan 08, 2021 at 01:01:10PM +, Qais Yousef wrote:
> On 01/08/21 10:27, Mel Gorman wrote:
> > for_each_cpu_wrap(cpu, cpus, target) {
> > - if (available_idle_cpu(cpu) || sched_idle_cpu(cpu))
> > + if (available_idle_cpu(cpu) || sched_idle_cpu(cpu)) {
> > +
On Thu, Dec 24, 2020 at 6:05 PM Adam Ford wrote:
> In preparation for adding new dev kits, move anything specific to the
> RZ/G2M from the SOM-level and baseboard-levels and move them to the
> kit-level. This allows the SOM and baseboard to be reused with
> other SoC's.
>
> Signed-off-by: Adam
Add maintainer entries for ROHM BD71815AGW drivers.
New regulator and GPIO drivers were introduced for these PMICs.
Signed-off-by: Matti Vaittinen
---
MAINTAINERS | 3 +++
1 file changed, 3 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 281de213ef47..eac1875ec788 100644
---
BD71815 contains similar RTC block as BD71828. Only the address offsets
seem different. Support also BD71815 RTC using rtc-bd70528.
Signed-off-by: Matti Vaittinen
---
drivers/rtc/Kconfig | 6 +++---
drivers/rtc/rtc-bd70528.c | 45 ---
2 files changed,
On Fri, Jan 8, 2021 at 1:22 AM Tony Lindgren wrote:
>
> * H. Nikolaus Schaller [201230 13:29]:
> > > Am 30.12.2020 um 13:55 schrieb Adam Ford :
> > > On Wed, Dec 30, 2020 at 2:43 AM Tony Lindgren wrote:
> > >>
> > >> At least for 4430, trying to use the single conversion mode eventually
> > >>
ROHM BD71815 also provide clk signal for RTC. Add control
for gating this clock.
Signed-off-by: Matti Vaittinen
clk Kconfig fix
---
drivers/clk/clk-bd718x7.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-bd718x7.c b/drivers/clk/clk-bd718x7.c
index
On Mon, 4 Jan 2021, la...@archlinux.org wrote:
> From: Filipe Laíns
>
> This new feature present in new devices replaces the old Battery Level
> Status (0x1000) feature. It keeps essentially the same information for
> levels (reporting critical, low, good and full) but makes these levels
>
On Thu, Dec 24, 2020 at 6:05 PM Adam Ford wrote:
> The keys on the baseboard are laid out in an diamond pattern, up, down,
> left, right and center. Update the descriptions to make it easier to
> read.
>
> Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
i.e. will queue in
Support voltage control for regulators on ROHM BD71815 PMIC.
ROHM BD71815 contains 5 bucks, 7 LDOs and a boost (intended for LED).
Bucks 1 and 2 support HW state based voltage level and enable states. Other
regulators support HW state based enable states. All bucks and LDOs 1-5
allow voltage
The helper for obtaining HW-state based DVS voltage levels currently only
works for regulators using linear-ranges. Extend support to regulators with
simple linear mappings and add also proper error path if pickable-ranges
regulators call this.
Signed-off-by: Matti Vaittinen
---
On Fri, 8 Jan 2021 at 13:24, Cristian Marussi wrote:
>
> On Thu, Jan 07, 2021 at 09:28:37AM -0500, Thara Gopinath wrote:
> >
> >
> > On 1/6/21 3:15 PM, Cristian Marussi wrote:
> > > Expose to the SCMI drivers a new devres managed common protocols API based
> > > on generic get/put methods and
On Thu, Dec 24, 2020 at 6:05 PM Adam Ford wrote:
> With the newly added configurable clock options, the audio CODEC can
> configure the mclk automatically. Add the reference to the versaclock.
> Since the devices on I2C5 can communicate at 400KHz, let's also increase
> that too
>
>
> Konrad, can you please test this below change without your change?
This brings no difference, a BUG still happens. We're still calling to_a6xx_gpu
on ANY device that's probed! Too bad it won't turn my A330 into an A640..
Also, relying on disabling LLCC in the config is out of question as it
On Wed 06-01-21 16:20:15, Milan Broz wrote:
> Hi,
>
> we use mlockall(MCL_CURRENT | MCL_FUTURE) / munlockall() in cryptsetup code
> and someone tried to use it with hardened memory allocator library.
>
> Execution time was increased to extreme (minutes) and as we found, the problem
> is in
On Fri, 8 Jan 2021 at 11:27, Mel Gorman wrote:
>
> On Tue, Dec 15, 2020 at 08:59:11AM +0100, Peter Zijlstra wrote:
> > On Tue, Dec 15, 2020 at 11:36:35AM +0800, Li, Aubrey wrote:
> > > On 2020/12/15 0:48, Peter Zijlstra wrote:
> > > > We compute the average cost of the total scan, but then use it
Some drivers need to translate voltage values to selectors prior regulator
registration. Currently a regulator_desc based list_voltages helper is only
exported for regulators using the linear_ranges. Export similar helper also
for regulators using simple linear mapping.
Signed-off-by: Matti
Support GPO(s) found from ROHM BD71815 power management IC. The IC has two
GPO pins but only one is properly documented in data-sheet. The driver
exposes by default only the documented GPO. The second GPO is connected to
E5 pin and is marked as GND in data-sheet. Control for this undocumented
pin
On Thu, Dec 24, 2020 at 6:05 PM Adam Ford wrote:
> The SoC was expecting two clock sources with different frequencies.
> One to support 44.1KHz and one to support 48KHz. With the newly added
> ability to configure the programmably clock, configure both clocks.
>
> Assign the rcar-sound clocks to
Add chip ID for ROHM BD71815 and PMIC so that drivers can identify
this IC.
Signed-off-by: Matti Vaittinen
---
include/linux/mfd/rohm-generic.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/mfd/rohm-generic.h b/include/linux/mfd/rohm-generic.h
index
Add core support for ROHM BD71815 Power Management IC.
The IC integrates regulators, a battery charger with a coulomb counter,
a real-time clock (RTC), clock gate and general-purpose outputs (GPO).
Signed-off-by: Matti Vaittinen
---
drivers/mfd/Kconfig | 15 +-
On Fri, Jan 08, 2021 at 09:52:28PM +0900, Dongseok Yi wrote:
> It is a workaround patch.
>
> UDP/IP header of UDP GROed frag_skbs are not updated even after NAT
> forwarding. Only the header of head_skb from ip_finish_output_gso ->
> skb_gso_segment is updated but following frag_skbs are not
Add binding documentation for regulators on ROHM BD71815 PMIC.
5 bucks, 7 LDOs and a boost for LED.
Signed-off-by: Matti Vaittinen
---
.../regulator/rohm,bd71815-regulator.yaml | 104 ++
1 file changed, 104 insertions(+)
create mode 100644
On Fri, Jan 8, 2021 at 11:44 AM Vincenzo Frascino
wrote:
>
> Hi Andrey,
>
> On 1/7/21 7:18 PM, Andrey Konovalov wrote:
> >> Boolean arguments are generally bad for legibility, hence I tend to avoid
> >> them.
> >> In this case exposing the constants does not seem a big issue especially
> >>
On Thu, Jan 07, 2021 at 04:45:33PM -0500, Andrea Arcangeli wrote:
> On Thu, Jan 07, 2021 at 04:25:25PM -0400, Jason Gunthorpe wrote:
> > On Thu, Jan 07, 2021 at 03:04:00PM -0500, Andrea Arcangeli wrote:
> >
> > > vmsplice syscall API is insecure allowing long term GUP PINs without
> > >
Document DT bindings for ROHM BD71815.
BD71815 is a single-chip power management IC mainly for battery-powered
portable devices. The IC integrates 5 bucks, 7 LDOs, a boost driver for
LED, a battery charger with a Coulomb counter, a real-time clock, a 32kHz
clock and two general-purpose outputs
The BD71828 allows configuring the clk32kout pin mode to CMOS or
open-drain. Add device-tree property for specifying the preferred mode.
Signed-off-by: Matti Vaittinen
---
.../devicetree/bindings/mfd/rohm,bd71828-pmic.yaml | 7 +++
1 file changed, 7 insertions(+)
diff --git
On Thu, 17 Dec 2020, Dmitry Torokhov wrote:
> > > Note that our HID support has greatly improved over the last 10 years,
> > > we may also consider reverting 6f8d9e26e7de ("hid-core.c: Adds all GTCO
> > > CalComp Digitizers and InterWrite School Products to blacklist") and see
> > > if GTCO
On Thu, Dec 24, 2020 at 6:05 PM Adam Ford wrote:
> When the board was added, clock drivers were being updated done at
> the same time to allow the versaclock driver to properly configure
> the modes. Unfortunately, the updates were not applied to the board
> files at the time they should have
The bd718x7 only needs a regmap from parent device. This can be
obtained by call to dev_get_regmap. Do not require parent to
populate the driver data for this.
Signed-off-by: Matti Vaittinen
---
Please note that this same change has been sent individually:
Most ROHM PMIC sub-devices only use the regmap pointer from
parent device. They can obtain this by dev_get_regamap so in
most cases the MFD device does not need to allocate and populate
the driver data. Simplify drivers by removing this.
The BD70528 still needs the access to watchdog mutex so
The ROHM BD71828 and BD71815 RTC drivers only need the regmap
pointer from parent. Regmap can be obtained via dev_get_regmap()
so do not require parent to populate driver data for that.
BD70528 on the other hand requires parent data to access the
watchdog so leave the parent data for BD70528 here
Patch series introducing support for ROHM BD71815 PMIC
Please note that this series depend on previously sent patches.
Already merged regulator patches (in regulator tree - not yet in Linus'
tree):
[PATCH] regulator: ROHM bd7: Do not depend on parent driver data
On Wed 06-01-21 08:42:39, Shakeel Butt wrote:
> On Wed, Jan 6, 2021 at 6:53 AM Michal Hocko wrote:
> >
> > On Thu 31-12-20 18:39:55, Shakeel Butt wrote:
> > > This patch adds swapcache stat for the cgroup v2. The swapcache
> > > represents the memory that is accounted against both the memory and
- Original Message -
> This causes bdev->bd_fsfreeze_sb to be set to NULL even if the call to
> thaw_super right after this line fail. So if a caller tries to call
> thaw_bdev() again after receiving such an error, that next call won't even
> try to call thaw_super(). Is that what we want
Hello
On 1/8/21 3:24 AM, Zheng Yongjun wrote:
Replace a comma between expression statements by a semicolon.
Can you add a "Fixes" tag here?
Dan
On Fri, 2021-01-08 at 10:05 +0100, Paul Kocialkowski wrote:
> Hi Ezequiel,
>
> On Thu 07 Jan 21, 16:08, Ezequiel Garcia wrote:
> > Happy to see this patch. It was on my TODO list,
> > but I hadn't had time to bringup my rk3326 device.
>
> Same here, I just had an occasion to use it again these
Fri, Jan 08, 2021 at 12:58:13AM CET, ja...@redhat.com wrote:
>On Mon, Dec 28, 2020 at 11:11:45AM +0100, Jiri Pirko wrote:
>> Fri, Dec 18, 2020 at 08:30:33PM CET, ja...@redhat.com wrote:
>> >This comes from an end-user request, where they're running multiple VMs on
>> >hosts with bonded interfaces
Hi Bean,
On Fri, 2021-01-08 at 12:29 +0100, Bean Huo wrote:
> On Wed, 2021-01-06 at 09:20 +0800, Can Guo wrote:
> > Hi Bean,
> >
> > On 2021-01-06 02:38, Bean Huo wrote:
> > > On Tue, 2021-01-05 at 09:07 +0800, Can Guo wrote:
> > > > On 2021-01-05 04:05, Bean Huo wrote:
> > > > > On Sat,
It is a workaround patch.
UDP/IP header of UDP GROed frag_skbs are not updated even after NAT
forwarding. Only the header of head_skb from ip_finish_output_gso ->
skb_gso_segment is updated but following frag_skbs are not updated.
A call path skb_mac_gso_segment -> inet_gso_segment ->
On 01/08/21 10:27, Mel Gorman wrote:
> for_each_cpu_wrap(cpu, cpus, target) {
> - if (available_idle_cpu(cpu) || sched_idle_cpu(cpu))
> + if (available_idle_cpu(cpu) || sched_idle_cpu(cpu)) {
> + /* Adjust cost of a successful scan */
> +
On Fri 2021-01-08 01:26:06, William Roche wrote:
> On 06/01/2021 05:35, Sergey Senozhatsky wrote:
> > On (21/01/04 16:15), “William Roche wrote:
> >> @@ -271,9 +280,8 @@ void panic(const char *fmt, ...)
> >> */
> >>atomic_notifier_call_chain(_notifier_list, 0, buf);
> >>
> >> - /* Call
On Sun, Dec 27, 2020 at 6:42 PM Wolfram Sang
wrote:
> R-Car V3U has a CPG different enough to not be a generic Gen3 CPG but
> similar enough to reuse code. Introduce a new CPG library, factor out
> the SD clock handling and hook it to the generic Gen3 CPG driver so we
> have an equal state. V3U
On Sun, Dec 27, 2020 at 6:42 PM Wolfram Sang
wrote:
> We want to reuse SD clock handling for other SoCs and, thus, need to
> generalize it. So, don't access cpg_quirks in that realm.
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-clk-for-v5.12.
On Sun, Dec 27, 2020 at 6:42 PM Wolfram Sang
wrote:
> We use the shiny new CPG library for that.
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-clk-for-v5.12.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots
601 - 700 of 983 matches
Mail list logo
