Re: WARNING: suspicious RCU usage in qrtr_ns_worker
syzbot has bisected this bug to:
commit e42671084361302141a09284fde9bbc14fdd16bf
Author: Manivannan Sadhasivam
Date: Thu May 7 12:53:06 2020 +
net: qrtr: Do not depend on ARCH_QCOM
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=105f775510
start commit: 7ae77150 Merge tag 'powerpc-5.8-1' of git://git.kernel.org..
git tree: upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=125f775510
console output: https://syzkaller.appspot.com/x/log.txt?x=145f775510
kernel config: https://syzkaller.appspot.com/x/.config?x=be4578b3f1083656
dashboard link: https://syzkaller.appspot.com/bug?extid=0f84f6eed90503da72fc
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1521944d10
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1298d24510
Reported-by: syzbot+0f84f6eed90503da7...@syzkaller.appspotmail.com
Fixes: e42671084361 ("net: qrtr: Do not depend on ARCH_QCOM")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [PATCH 5/5] connector: Create connector per namespace
Hi Matt,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on ipvs/master]
[also build test WARNING on dm/for-next linux/master linus/master v5.8-rc3
next-20200701]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Matt-Bennett/RFC-connector-Add-network-namespace-awareness/20200702-083030
base: https://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs.git master
config: powerpc-pmac32_defconfig (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/connector/connector.c: In function 'cn_netlink_send_mult':
>> drivers/connector/connector.c:71:18: warning: comparison is always false due
>> to limited range of data type [-Wtype-limits]
71 | if (!msg || len < 0)
| ^
drivers/connector/connector.c: At top level:
drivers/connector/connector.c:238:5: warning: no previous prototype for
'cn_add_callback_one' [-Wmissing-prototypes]
238 | int cn_add_callback_one(struct net *net, struct cb_id *id, const
char *name,
| ^~~
vim +71 drivers/connector/connector.c
30
31 /*
32 * Sends mult (multiple) cn_msg at a time.
33 *
34 * msg->seq and msg->ack are used to determine message genealogy.
35 * When someone sends message it puts there locally unique sequence
36 * and random acknowledge numbers. Sequence number may be copied into
37 * nlmsghdr->nlmsg_seq too.
38 *
39 * Sequence number is incremented with each message to be sent.
40 *
41 * If we expect a reply to our message then the sequence number in
42 * received message MUST be the same as in original message, and
43 * acknowledge number MUST be the same + 1.
44 *
45 * If we receive a message and its sequence number is not equal to the
46 * one we are expecting then it is a new message.
47 *
48 * If we receive a message and its sequence number is the same as one
49 * we are expecting but it's acknowledgement number is not equal to
50 * the acknowledgement number in the original message + 1, then it is
51 * a new message.
52 *
53 * If msg->len != len, then additional cn_msg messages are expected
following
54 * the first msg.
55 *
56 * The message is sent to, the portid if given, the group if given,
both if
57 * both, or if both are zero then the group is looked up and sent there.
58 */
59 int cn_netlink_send_mult(struct net *net, struct cn_msg *msg, u16 len,
60 u32 portid, u32 __group, gfp_t gfp_mask)
61 {
62 struct cn_callback_entry *__cbq;
63 unsigned int size;
64 struct sk_buff *skb;
65 struct nlmsghdr *nlh;
66 struct cn_msg *data;
67 struct cn_dev *dev = &(net->cdev);
68 u32 group = 0;
69 int found = 0;
70
> 71 if (!msg || len < 0)
72 return -EINVAL;
73
74 if (portid || __group) {
75 group = __group;
76 } else {
77 spin_lock_bh(>cbdev->queue_lock);
78 list_for_each_entry(__cbq, >cbdev->queue_list,
79 callback_entry) {
80 if (cn_cb_equal(&__cbq->id.id, >id)) {
81 found = 1;
82 group = __cbq->group;
83 break;
84 }
85 }
86 spin_unlock_bh(>cbdev->queue_lock);
87
88 if (!found)
89 return -ENODEV;
90 }
91
92 if (!portid && !netlink_has_listeners(dev->nls, group))
93 return -ESRCH;
94
95 size = sizeof(*msg) + len;
96
97 skb = nlmsg_new(size, gfp_mask);
98 if (!skb)
99 return -ENOMEM;
100
101 nlh = nlmsg_put(skb, 0, msg->seq, NLMSG_DONE, size, 0);
102 if (!nlh) {
103 kfree_skb(skb);
104 return -E
Re: [PATCH v4 12/37] PM / devfreq: tegra20: Use MC timings for building OPP table
02.07.2020 08:43, Dmitry Osipenko пишет:
> 02.07.2020 08:30, Chanwoo Choi пишет:
>> On 7/2/20 2:07 PM, Dmitry Osipenko wrote:
>>> 02.07.2020 07:18, Chanwoo Choi пишет:
Hi Dmitry,
On 6/9/20 10:13 PM, Dmitry Osipenko wrote:
> The clk_round_rate() won't be usable for building OPP table once
> interconnect support will be added to the EMC driver because that CLK API
> function limits the rounded rate based on the clk rate that is imposed by
> active clk-users, and thus, the rounding won't work as expected if
> interconnect will set the minimum EMC clock rate before devfreq driver is
> loaded. The struct tegra_mc contains memory timings which could be used by
> the devfreq driver for building up OPP table instead of rounding clock
> rate, this patch implements this idea.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra20-devfreq.c | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/devfreq/tegra20-devfreq.c
> b/drivers/devfreq/tegra20-devfreq.c
> index 6469dc69c5e0..bf504ca4dea2 100644
> --- a/drivers/devfreq/tegra20-devfreq.c
> +++ b/drivers/devfreq/tegra20-devfreq.c
> @@ -123,8 +123,7 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> {
> struct tegra_devfreq *tegra;
> struct tegra_mc *mc;
> - unsigned long max_rate;
> - unsigned long rate;
> + unsigned int i;
> int err;
>
> mc = tegra_get_memory_controller();
> @@ -151,12 +150,17 @@ static int tegra_devfreq_probe(struct
> platform_device *pdev)
>
> tegra->regs = mc->regs;
>
> - max_rate = clk_round_rate(tegra->emc_clock, ULONG_MAX);
> -
> - for (rate = 0; rate <= max_rate; rate++) {
> - rate = clk_round_rate(tegra->emc_clock, rate);
> + if (!mc->num_timings) {
Could you explain what is meaning of 'num_timing?
>>>
>>> The num_timings is the number of memory timings defined in a
>>> device-tree. One timing configuration per memory clock rate.
>>
>> OK. I understand.
>>
>>>
Also, why add the opp entry in case of mc->num_timings is zero?
>>>
>>> Timings may be not defined in some device-trees at all and in this case
>>> memory always running on a fixed clock rate.
>>
>> You mean that 'timings' information is optional?
>
> Yes
>
> Actually, looks like I missed to properly test this case where timings
> are missing in DT and it shouldn't work with the current code. I'll fix
> it in the next version.
>
>>>
>>> The devfreq driver won't be practically useful if mc->num_timings is
>>> zero since memory frequency can't be changed, but anyways we'd want to
>>> load the devfreq driver in order to prevent confusion about why it's not
>>> loaded.
>>>
>>> For example, you may ask somebody to show contents of
>>> /sys/class/devfreq/tegra20-devfreq/trans_stat and the person says to you
>>> that this file doesn't exist, now you'll have to figure out what
>>> happened to the devfreq driver.
>>
>> I understand why add OPP entry point when timing is not defined on DT.
>> But, actually, I think that you better to change 'timings' info is mandatory
>> instead of optional. Because the devfreq driver is for DVFS
>> and the driver supporting DVFS have to have the frequency information
>> like OPP.
That's what I initially did by bailing out from driver's probe if
timings info is missing, until ran into a situation described above :)
>> Or,
>> If you want to keep 'timing' is optional on DT,
>> I recommend that you add one timing data to tegra mc driver
>> when DT doesn't include the any timing information
>> I think that is it more clear.
>
> Okay, I'll move it into the MC driver in the next version.
>
> Thank you for the review!
>
Re: [PATCH V4 3/5] clk: imx: Support building i.MX common clock driver as module
On Thu, Jul 2, 2020 at 11:26 AM Anson Huang wrote:
[...]
> > > @@ -143,16 +148,18 @@ void imx_cscmr1_fixup(u32 *val)
> > > static int imx_keep_uart_clocks;
> > > static struct clk ** const *imx_uart_clocks;
> > >
> > > -static int __init imx_keep_uart_clocks_param(char *str)
> > > +static int __maybe_unused imx_keep_uart_clocks_param(char *str)
> > > {
> > > imx_keep_uart_clocks = 1;
> > >
> > > return 0;
> > > }
> > > +#ifndef MODULE
> > > __setup_param("earlycon", imx_keep_uart_earlycon,
> > > imx_keep_uart_clocks_param, 0);
> > > __setup_param("earlyprintk", imx_keep_uart_earlyprintk,
> > > imx_keep_uart_clocks_param, 0);
> >
> > I feel not only the __setup_param, the whole logic of keep_uart_clocks
> > are not needed for Module case. Is it true?
>
> Yes, but the 'keep_uart_clocks' is false by default and the function
> imx_keep_uart_clocks_param()
> already has '__maybe_unused', it does NOT impact anything if it is for module
> build, so I did NOT
> add the #ifndef check for them, just to keep code easy and clean.
>
IMHO do not compile them is a more easy and clean way. Then users
don't have to look into the code logic
which is meaingless for Module case.
BTW, it really does not make any sense to only condionally compile
__setup_parm() but left
the param functions definition to be handled by __maybe_unnused.
They're together part of code, aren't they?
Regards
Aisheng
Regards
Aisheng
> Thanks,
> Anson
>
RE: [PATCH V4 5/5] clk: imx8qxp: Support building i.MX8QXP clock driver as module
> Subject: Re: [PATCH V4 5/5] clk: imx8qxp: Support building i.MX8QXP clock
> driver as module
>
> On Thu, Jul 2, 2020 at 11:55 AM Anson Huang
> wrote:
> [...]
> > > > +{
> > > > + return platform_driver_register(_lpcg_clk_driver);
> > > > +}
> > > > +device_initcall(imx8qxp_lpcg_clk_init);
> > >
> > > Any reason to change to device_initcall which looks a bit strange?
> > > Is it because the following line?
> > > +obj-$(CONFIG_MXC_CLK_SCU) += clk-imx-scu.o clk-imx-lpcg-scu.o
> > > But it looks to me they're still two modules. Aren't they?
> >
> > It is suggested by Arnd to NOT use builtin_platform_driver(), in order
> > to support module unload, although the clock driver normally does NOT
> > support remove, but it is better to follow the right way.
> >
>
> By expanding builtin_platform_driver() marcro, you will find your patch is
> exactly doing the same thing as buildin_platform_driver() which obivously is
> unneccesary.
>
> #define builtin_platform_driver(__platform_driver) \
> builtin_driver(__platform_driver, platform_driver_register) #define
> builtin_driver(__driver, __register, ...) \
>
> static int __init __driver##_init(void) \ { \
> return __register(&(__driver) , ##__VA_ARGS__); \ } \
> device_initcall(__driver##_init);
>
> If we want to support unload, we need a .remove() callback as current clocks
> are not allocated by devm_().
> If don't support, we probably can use builtin_platform_driver() first and
> switch to module_platform_driver() in the future once the driver supports
> release resource properly.
>
Yes, that is why I use the device_initcall() to make it exactly same as
builtin_driver(),
and also yes that i.MX clock driver does NOT support module unload, so .remove()
is NOT implemented, I am fine with either way, just try to address Arnd's
comment.
Hi, Arnd
What do you think? Do you agree to keep using the builtin_driver()?
Thanks,
Anson
Re: linux-next: Signed-off-by missing for commit in the char-misc.current tree
On Thu, Jul 02, 2020 at 08:01:10AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> 853eab68afc8 ("Revert "zram: convert remaining CLASS_ATTR() to
> CLASS_ATTR_RO()"")
>
> is missing a Signed-off-by from its author.
Known issue, I had to override the check as I was trying to keep Wade's
authorship information here.
thanks,
greg k-h
[PATCH v2] leds: core: Flush scheduled work for system suspend
Sometimes LED won't be turned off by LED_CORE_SUSPENDRESUME flag upon
system suspend.
led_set_brightness_nopm() uses schedule_work() to set LED brightness.
However, there's no guarantee that the scheduled work gets executed
because no one flushes the work.
So flush the scheduled work to make sure LED gets turned off.
Signed-off-by: Kai-Heng Feng
---
v2:
- Use flush_work() instead.
drivers/leds/led-class.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 3363a6551a70..cc3929f858b6 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -173,6 +173,7 @@ void led_classdev_suspend(struct led_classdev *led_cdev)
{
led_cdev->flags |= LED_SUSPENDED;
led_set_brightness_nopm(led_cdev, 0);
+ flush_work(_cdev->set_brightness_work);
}
EXPORT_SYMBOL_GPL(led_classdev_suspend);
--
2.17.1
Re: [PATCH v4 12/37] PM / devfreq: tegra20: Use MC timings for building OPP table
02.07.2020 08:30, Chanwoo Choi пишет:
> On 7/2/20 2:07 PM, Dmitry Osipenko wrote:
>> 02.07.2020 07:18, Chanwoo Choi пишет:
>>> Hi Dmitry,
>>>
>>> On 6/9/20 10:13 PM, Dmitry Osipenko wrote:
The clk_round_rate() won't be usable for building OPP table once
interconnect support will be added to the EMC driver because that CLK API
function limits the rounded rate based on the clk rate that is imposed by
active clk-users, and thus, the rounding won't work as expected if
interconnect will set the minimum EMC clock rate before devfreq driver is
loaded. The struct tegra_mc contains memory timings which could be used by
the devfreq driver for building up OPP table instead of rounding clock
rate, this patch implements this idea.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra20-devfreq.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/devfreq/tegra20-devfreq.c
b/drivers/devfreq/tegra20-devfreq.c
index 6469dc69c5e0..bf504ca4dea2 100644
--- a/drivers/devfreq/tegra20-devfreq.c
+++ b/drivers/devfreq/tegra20-devfreq.c
@@ -123,8 +123,7 @@ static int tegra_devfreq_probe(struct platform_device
*pdev)
{
struct tegra_devfreq *tegra;
struct tegra_mc *mc;
- unsigned long max_rate;
- unsigned long rate;
+ unsigned int i;
int err;
mc = tegra_get_memory_controller();
@@ -151,12 +150,17 @@ static int tegra_devfreq_probe(struct
platform_device *pdev)
tegra->regs = mc->regs;
- max_rate = clk_round_rate(tegra->emc_clock, ULONG_MAX);
-
- for (rate = 0; rate <= max_rate; rate++) {
- rate = clk_round_rate(tegra->emc_clock, rate);
+ if (!mc->num_timings) {
>>>
>>> Could you explain what is meaning of 'num_timing?
>>
>> The num_timings is the number of memory timings defined in a
>> device-tree. One timing configuration per memory clock rate.
>
> OK. I understand.
>
>>
>>> Also, why add the opp entry in case of mc->num_timings is zero?
>>
>> Timings may be not defined in some device-trees at all and in this case
>> memory always running on a fixed clock rate.
>
> You mean that 'timings' information is optional?
Yes
Actually, looks like I missed to properly test this case where timings
are missing in DT and it shouldn't work with the current code. I'll fix
it in the next version.
>>
>> The devfreq driver won't be practically useful if mc->num_timings is
>> zero since memory frequency can't be changed, but anyways we'd want to
>> load the devfreq driver in order to prevent confusion about why it's not
>> loaded.
>>
>> For example, you may ask somebody to show contents of
>> /sys/class/devfreq/tegra20-devfreq/trans_stat and the person says to you
>> that this file doesn't exist, now you'll have to figure out what
>> happened to the devfreq driver.
>
> I understand why add OPP entry point when timing is not defined on DT.
> But, actually, I think that you better to change 'timings' info is mandatory
> instead of optional. Because the devfreq driver is for DVFS
> and the driver supporting DVFS have to have the frequency information
> like OPP.
>
> Or,
> If you want to keep 'timing' is optional on DT,
> I recommend that you add one timing data to tegra mc driver
> when DT doesn't include the any timing information
> I think that is it more clear.
Okay, I'll move it into the MC driver in the next version.
Thank you for the review!
Re: [PATCH V4 5/5] clk: imx8qxp: Support building i.MX8QXP clock driver as module
On Thu, Jul 2, 2020 at 11:55 AM Anson Huang wrote:
[...]
> > > +{
> > > + return platform_driver_register(_lpcg_clk_driver);
> > > +}
> > > +device_initcall(imx8qxp_lpcg_clk_init);
> >
> > Any reason to change to device_initcall which looks a bit strange?
> > Is it because the following line?
> > +obj-$(CONFIG_MXC_CLK_SCU) += clk-imx-scu.o clk-imx-lpcg-scu.o
> > But it looks to me they're still two modules. Aren't they?
>
> It is suggested by Arnd to NOT use builtin_platform_driver(), in order to
> support module
> unload, although the clock driver normally does NOT support remove, but it is
> better to
> follow the right way.
>
By expanding builtin_platform_driver() marcro, you will find your
patch is exactly doing the same thing
as buildin_platform_driver() which obivously is unneccesary.
#define builtin_platform_driver(__platform_driver) \
builtin_driver(__platform_driver, platform_driver_register)
#define builtin_driver(__driver, __register, ...) \
static int __init __driver##_init(void) \
{ \
return __register(&(__driver) , ##__VA_ARGS__); \
} \
device_initcall(__driver##_init);
If we want to support unload, we need a .remove() callback as current
clocks are not allocated by devm_().
If don't support, we probably can use builtin_platform_driver() first
and switch to module_platform_driver()
in the future once the driver supports release resource properly.
Regards
Aisheng
> The change in Makefile is just to link scu/lpcg library to i.MX8QXP clk
> driver, so that we can
> get rid of exports and below 2 .ko are needed for all i.MX SoCs with SCU
> inside as per your
> saying of i.MX8QXP clock driver can be extended for future SoCs with SCU.
>
> clk-imx-lpcg-scu.ko
> clk-imx-scu.ko
>
> Thanks,
> Anson
Re: UART/TTY console deadlock
On (20/07/02 14:12), Sergey Senozhatsky wrote: > Date: Thu, 2 Jul 2020 14:12:13 +0900 > From: Sergey Senozhatsky > To: Tony Lindgren > Cc: Sergey Senozhatsky , Petr Mladek > , Andy Shevchenko , Raul > Rangel , Sergey Senozhatsky > , linux-kernel > , Greg Kroah-Hartman > , Andy Shevchenko > , k...@linutronix.de, "S, Shirish" > , Peter Zijlstra , John Ogness > , Steven Rostedt > Subject: Re: UART/TTY console deadlock > Message-ID: <20200702051213.GB3450@jagdpanzerIV.localdomain> > > On (20/06/30 11:02), Tony Lindgren wrote: > > This conditional disable for irq_shared does not look nice to me > > from the other device point of view :) > > > > Would it be possible to just set up te dummy interrupt handler > > for the startup, then change it back afterwards? See for example > > omap8250_no_handle_irq(). > > I think we can do it. serial8250_do_startup() and irq handler take > port->lock, so they should be synchronized. Hmm, hold on. Why does it disable IRQ in the first place? IRQ handlers should grab the port->lock. So if there is already running IRQ, then serial8250_do_startup() will wait until IRQ handler unlocks the port->lock. If serial8250_do_startup() grabs the port->lock first, then IRQ will wait for serial8250_do_startup() to unlock it. serial8250_do_startup() does not release the port->unlock until its done: spin_lock_irqsave(>lock, flags); wait_for_xmitr(up, UART_LSR_THRE); serial_port_out_sync(port, UART_IER, UART_IER_THRI); udelay(1); /* allow THRE to set */ iir1 = serial_port_in(port, UART_IIR); serial_port_out(port, UART_IER, 0); serial_port_out_sync(port, UART_IER, UART_IER_THRI); udelay(1); /* allow a working UART time to re-assert THRE */ iir = serial_port_in(port, UART_IIR); serial_port_out(port, UART_IER, 0); spin_unlock_irqrestore(>lock, flags); so IRQ will not see the inconsistent device state. What exactly is the purpose of disable_irq_nosync()? Can we just remove disable_irq_nosync()/enable_irq() instead? Are there any IRQ handlers that don't acquire the port->lock? -ss
Re: [v2] Documentation: Coccinelle: fix typos and command example
On Thu, 2 Jul 2020, Matthew Wilcox wrote: > On Wed, Jul 01, 2020 at 07:52:58AM -0700, Randy Dunlap wrote: > > On 7/1/20 6:32 AM, Markus Elfring wrote: > > >>> How do you think about to use the following command variant > > >>> for the adjustment of the software documentation? > > >>> > > >>> +make C=1 CHECK='scripts/coccicheck' 'path/to/file.o' > > >> > > >> I don't understand the reason for that change... > > > > IOW, your "patch" needs justification and/or explanation. It was missing > > that info. > > What Markus is trying so completely ineptly to say is that > make C=1 CHECK=scripts/coccicheck path/to/file.c > doesn't work. You need to use the .o suffix to check the .c file. Thanks Matthew for this very helpful information. julia
Re: [PATCH 4/4] writeback: remove bdi->congested_fn
On Wed, Jul 1, 2020 at 2:06 AM Christoph Hellwig wrote: > > Except for pktdvd, the only places setting congested bits are file > systems that allocate their own backing_dev_info structures. And > pktdvd is a deprecated driver that isn't useful in stack setup > either. So remove the dead congested_fn stacking infrastructure. > > Signed-off-by: Christoph Hellwig For md bits: Acked-by: Song Liu
Re: [PATCH v2 5/7] driver core: Add device location to "struct device" and expose it in sysfs
On Thu, Jul 2, 2020 at 4:07 AM Rajat Jain wrote: > > *snip* > > > > I guess it would make sense to have an attribute for user space to > > > write to in order to make the kernel reject device plug-in events > > > coming from a given port or connector, but the kernel has no reliable > > > means to determine *which* ports or connectors are "safe", and even if > > > there was a way for it to do that, it still may not agree with user > > > space on which ports or connectors should be regarded as "safe". > > > > Again, we have been doing this for USB devices for a very long time, PCI > > shouldn't be any different. Why people keep ignoring working solutions > > is beyond me, there's nothing "special" about PCI devices here for this > > type of "worry" or reasoning to try to create new solutions. > > > > So, again, I ask, go do what USB does, and to do that, take the logic > > out of the USB core, make it bus-agnositic, and _THEN_ add it to the PCI > > code. Why the original submitter keeps ignoring my request to do this > > is beyond me, I guess they like making patches that will get rejected :( > > IMHO I'm actually trying to precisely do what I think was the > conclusion of our discussion, and then some changes because of the > further feedback I received on those patches. Let's take a step back > and please allow me to explain how I got here (my apologies but this > spans a couple of threads, and I"m trying to tie them all together > here): The previous thread had some suggestions, but no real conclusions. That's probably why we're still arguing about it... > GOAL: To allow user space to control what (PCI) drivers he wants to > allow on external (thunderbolt) ports. There was a lot of debate about > the need for such a policy at > https://lore.kernel.org/linux-pci/CACK8Z6GR7-wseug=ttvyrarvzx_ao2geoldnbwjtb+5y7vw...@mail.gmail.com/ > with the final conclusion that it should be OK to implement such a > policy in userspace, as long as the policy is not implemented in the > kernel. The kernel only needs to expose bits & info that is needed by > the userspace to implement such a policy, and it can be used in > conjunction with "drivers_autoprobe" to implement this policy: > > > That's an odd thing, but sure, if you want to write up such a policy for > your systems, great. But that policy does not belong in the kernel, it > belongs in userspace. > > > 1) The post > https://lore.kernel.org/linux-pci/20200609210400.GA1461839@bjorn-Precision-5520/ > lists out the approach that was agreed on. Replicating it here: > --- > - Expose the PCI pdev->untrusted bit in sysfs. We don't expose this > today, but doing so would be trivial. I think I would prefer a > sysfs name like "external" so it's more descriptive and less of a > judgment. > > This comes from either the DT "external-facing" property or the > ACPI "ExternalFacingPort" property. > > - All devices present at boot are enumerated. Any statically built > drivers will bind to them before any userspace code runs. > > If you want to keep statically built drivers from binding, you'd > need to invent some mechanism so pci_driver_init() could clear > drivers_autoprobe after registering pci_bus_type. > > - Early userspace code prevents modular drivers from automatically > binding to PCI devices: > > echo 0 > /sys/bus/pci/drivers_autoprobe > > This prevents modular drivers from binding to all devices, whether > present at boot or hot-added. > > - Userspace code uses the sysfs "bind" file to control which drivers > are loaded and can bind to each device, e.g., > > echo :02:00.0 > /sys/bus/pci/drivers/nvme/bind I think this is a reasonable suggestion. However, as Greg pointed out it's gratuitously different to what USB does for no real reason. > --- > 2) As part of implementing the above agreed approach, when I exposed > PCI "untrusted" attribute to userspace, it ran into discussion that > concluded that instead of this, the device core should be enhanced > with a location attribute. > https://lore.kernel.org/linux-pci/20200618184621.ga446...@kroah.com/ > --- > ... > The attribute should be called something like "location" or something > like that (naming is hard), as you don't always know if something is > external or not (it could be internal, it could be unknown, it could be > internal to an external device that you trust (think PCI drawers for > "super" computers that are hot pluggable but yet really part of the > internal bus). > > "trust" has no direct relation to the location, except in a policy of > what you wish to do with that
Re: [PATCH] leds: core: Use blocking op for system suspend
> On Jul 2, 2020, at 05:28, Jacek Anaszewski wrote:
>
> Hi Kai-Heng,
>
> Thank you for the patch.
>
> On 7/1/20 11:35 AM, Kai-Heng Feng wrote:
>> Sometimes LED won't be turned off by LED_CORE_SUSPENDRESUME flag upon
>> system suspend.
>
> Just out of curiosity - are you experiencing that on some hardware?
Yes, mute and micmute LED on laptops sometimes are still on during
suspend-to-idle.
>
>> led_set_brightness_nopm() uses schedule_work() to set LED brightness.
>> However, there's no guarantee that the scheduled work gets executed
>> because no one calls flush_scheduled_work().
>> As flush_scheduled_work() may affect other drivers' suspend routines,
>> take a more contained approach which uses blocking op to make sure the
>> LED gets turned off.
>> Signed-off-by: Kai-Heng Feng
>> ---
>> drivers/leds/led-core.c | 5 +
>> 1 file changed, 5 insertions(+)
>> diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
>> index f1f718dbe0f8..9a5bfcd7a704 100644
>> --- a/drivers/leds/led-core.c
>> +++ b/drivers/leds/led-core.c
>> @@ -269,6 +269,11 @@ EXPORT_SYMBOL_GPL(led_set_brightness);
>> void led_set_brightness_nopm(struct led_classdev *led_cdev,
>>enum led_brightness value)
>> {
>> +
>> +if (led_cdev->flags & LED_SUSPENDED &&
>> +!__led_set_brightness_blocking(led_cdev, value))
>> +return;
>> +
>
> This function is "nopm" for a reason - we do not make here any
> pm management related operations.
>
> Instead of that, please just add
>
> flush_work(_cdev->set_brightness_work);
>
> at the end of led_classdev_suspend()
>
> in drivers/leds/led-class.c.
Right, will send v2.
Kai-Heng
>
> --
> Best regards,
> Jacek Anaszewski
Re: [PATCH v4 12/37] PM / devfreq: tegra20: Use MC timings for building OPP table
On 7/2/20 2:07 PM, Dmitry Osipenko wrote:
> 02.07.2020 07:18, Chanwoo Choi пишет:
>> Hi Dmitry,
>>
>> On 6/9/20 10:13 PM, Dmitry Osipenko wrote:
>>> The clk_round_rate() won't be usable for building OPP table once
>>> interconnect support will be added to the EMC driver because that CLK API
>>> function limits the rounded rate based on the clk rate that is imposed by
>>> active clk-users, and thus, the rounding won't work as expected if
>>> interconnect will set the minimum EMC clock rate before devfreq driver is
>>> loaded. The struct tegra_mc contains memory timings which could be used by
>>> the devfreq driver for building up OPP table instead of rounding clock
>>> rate, this patch implements this idea.
>>>
>>> Signed-off-by: Dmitry Osipenko
>>> ---
>>> drivers/devfreq/tegra20-devfreq.c | 18 +++---
>>> 1 file changed, 11 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/tegra20-devfreq.c
>>> b/drivers/devfreq/tegra20-devfreq.c
>>> index 6469dc69c5e0..bf504ca4dea2 100644
>>> --- a/drivers/devfreq/tegra20-devfreq.c
>>> +++ b/drivers/devfreq/tegra20-devfreq.c
>>> @@ -123,8 +123,7 @@ static int tegra_devfreq_probe(struct platform_device
>>> *pdev)
>>> {
>>> struct tegra_devfreq *tegra;
>>> struct tegra_mc *mc;
>>> - unsigned long max_rate;
>>> - unsigned long rate;
>>> + unsigned int i;
>>> int err;
>>>
>>> mc = tegra_get_memory_controller();
>>> @@ -151,12 +150,17 @@ static int tegra_devfreq_probe(struct platform_device
>>> *pdev)
>>>
>>> tegra->regs = mc->regs;
>>>
>>> - max_rate = clk_round_rate(tegra->emc_clock, ULONG_MAX);
>>> -
>>> - for (rate = 0; rate <= max_rate; rate++) {
>>> - rate = clk_round_rate(tegra->emc_clock, rate);
>>> + if (!mc->num_timings) {
>>
>> Could you explain what is meaning of 'num_timing?
>
> The num_timings is the number of memory timings defined in a
> device-tree. One timing configuration per memory clock rate.
OK. I understand.
>
>> Also, why add the opp entry in case of mc->num_timings is zero?
>
> Timings may be not defined in some device-trees at all and in this case
> memory always running on a fixed clock rate.
You mean that 'timings' information is optional?
>
> The devfreq driver won't be practically useful if mc->num_timings is
> zero since memory frequency can't be changed, but anyways we'd want to
> load the devfreq driver in order to prevent confusion about why it's not
> loaded.
>
> For example, you may ask somebody to show contents of
> /sys/class/devfreq/tegra20-devfreq/trans_stat and the person says to you
> that this file doesn't exist, now you'll have to figure out what
> happened to the devfreq driver.
I understand why add OPP entry point when timing is not defined on DT.
But, actually, I think that you better to change 'timings' info is mandatory
instead of optional. Because the devfreq driver is for DVFS
and the driver supporting DVFS have to have the frequency information
like OPP.
Or,
If you want to keep 'timing' is optional on DT,
I recommend that you add one timing data to tegra mc driver
when DT doesn't include the any timing information
I think that is it more clear.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH 17/23] proc: add a read_iter method to proc proc_ops
On Wed, Jul 01, 2020 at 10:27:51PM +0100, Al Viro wrote: > On Wed, Jul 01, 2020 at 10:09:45PM +0200, Christoph Hellwig wrote: > > This will allow proc files to implement iter read semantics. > > *UGH* > > You are introducing file_operations with both ->read() and ->read_iter(); > worse, in some cases they are not equivalent. Sure, ->read() takes > precedence right now, but... why not a separate file_operations for > ->read_iter-capable files? I looked at that initially. We'd need to more instances as there already are two due to compat stuff. If that is preferably I can switch to that version. > I really hate the fallbacks of that sort - they tend to be brittle > as hell. And while we are at it, I'm not sure that your iter_read() > has good cause to be non-static. The other user of it is seq_file, which as-is should go away, but will probably keep the occasional version of it in the caller. I just got really tired of reimplementing it a few times.
RE: [PATCH] exfat: implement "quiet" option for setattr
>
> if (((attr->ia_valid & ATTR_UID) &&
>!uid_eq(attr->ia_uid, sbi->options.fs_uid)) || @@ -322,6 +325,12
> @@ int
> exfat_setattr(struct dentry *dentry, struct iattr *attr)
> goto out;
You should remove goto statement and curly braces here to reach if error
condition.
> }
>
> + if (error) {
> + if (sbi->options.quiet)
> + error = 0;
> + goto out;
> + }
Re: [PATCH 19/23] sysctl: Call sysctl_head_finish on error
On Thu, Jul 02, 2020 at 01:32:40AM +0100, Matthew Wilcox wrote:
> On Wed, Jul 01, 2020 at 10:09:47PM +0200, Christoph Hellwig wrote:
> > From: "Matthew Wilcox (Oracle)"
> >
> > This error path returned directly instead of calling sysctl_head_finish().
> >
> > Fixes: ef9d965bc8b6 ("sysctl: reject gigantic reads/write to sysctl files")
> > Signed-off-by: Matthew Wilcox (Oracle)
>
> I think this one needs to go to Linus before 5.8, not get stuck in the
> middle of a large patch series.
I've only kept it here because it didn't show up in Linus tree yet.
If you send it and it gets picked up I can trivially drop it.
Re: [PATCH] hwmon:max6697: Allow max6581 to create tempX_offset attributes
On Thu, Jul 02, 2020 at 01:42:23AM +, Chu Lin wrote: > Per max6581, reg 4d and reg 4e is used for temperature read offset. > This patch will let the user specify the temperature read offset for > max6581. This patch is tested on max6581 and only applies to max6581. > Patchwork received four versions of this patch, with two different subject lines. How am I supposed to know which one to look at ? Guenter
Re: UART/TTY console deadlock
On (20/06/30 11:02), Tony Lindgren wrote:
> This conditional disable for irq_shared does not look nice to me
> from the other device point of view :)
>
> Would it be possible to just set up te dummy interrupt handler
> for the startup, then change it back afterwards? See for example
> omap8250_no_handle_irq().
I think we can do it. serial8250_do_startup() and irq handler take
port->lock, so they should be synchronized.
Something like this then?
---
diff --git a/drivers/tty/serial/8250/8250_port.c
b/drivers/tty/serial/8250/8250_port.c
index f77bf820b7a3..61ad6f5f0f88 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2140,6 +2140,11 @@ static void serial8250_put_poll_char(struct uart_port
*port,
#endif /* CONFIG_CONSOLE_POLL */
+static int serial8250_dummy_handle_irq(struct uart_port *port)
+{
+ return 0;
+}
+
int serial8250_do_startup(struct uart_port *port)
{
struct uart_8250_port *up = up_to_u8250p(port);
@@ -2271,6 +2276,9 @@ int serial8250_do_startup(struct uart_port *port)
if (port->irq && !(up->port.flags & UPF_NO_THRE_TEST)) {
unsigned char iir1;
+ int (*handler)(struct uart_port *);
+
+ handler = port->handle_irq;
/*
* Test for UARTs that do not reassert THRE when the
* transmitter is idle and the interrupt has already
@@ -2280,8 +2288,7 @@ int serial8250_do_startup(struct uart_port *port)
* allow register changes to become visible.
*/
spin_lock_irqsave(>lock, flags);
- if (up->port.irqflags & IRQF_SHARED)
- disable_irq_nosync(port->irq);
+ port->handle_irq = serial8250_dummy_handle_irq;
wait_for_xmitr(up, UART_LSR_THRE);
serial_port_out_sync(port, UART_IER, UART_IER_THRI);
@@ -2293,8 +2300,7 @@ int serial8250_do_startup(struct uart_port *port)
iir = serial_port_in(port, UART_IIR);
serial_port_out(port, UART_IER, 0);
- if (port->irqflags & IRQF_SHARED)
- enable_irq(port->irq);
+ port->handle_irq = handler;
spin_unlock_irqrestore(>lock, flags);
/*
Re: [PATCH v2 7/7] arm64: dts: mt8183: Add krane-sku176 board
On Thu, Jun 25, 2020 at 6:18 PM Enric Balletbo i Serra
wrote:
>
> Also known as the Lenovo IdeaPad Duet Chromebook.
>
> There are different krane boards with shared resources, hence a
> mt8183-kukui-krane.dtsi was created for easily introduce future new
> boards. The same happens with the baseboard codenamed kukui where
> different variants, apart from kukui variant can take advantage of the
> shared resources.
>
> Signed-off-by: Ben Ho
> [originally created by Ben Ho but adapted and ported to mainline]
> Signed-off-by: Enric Balletbo i Serra
Tested-by: Hsin-Yi Wang
> ---
>
> Changes in v2:
> - Move adding #phy-cells out of this patch. (Matthias Brugger)
>
> arch/arm64/boot/dts/mediatek/Makefile | 1 +
> .../mediatek/mt8183-kukui-krane-sku176.dts| 18 +
> .../boot/dts/mediatek/mt8183-kukui-krane.dtsi | 343
> .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 788 ++
> 4 files changed, 1150 insertions(+)
> create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dts
> create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi
> create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
>
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile
> b/arch/arm64/boot/dts/mediatek/Makefile
> index 848218f55bc1d..708fc60fa589a 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -12,4 +12,5 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-hana.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-hana-rev7.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8516-pumpkin.dtb
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dts
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dts
> new file mode 100644
> index 0..47113e275cb52
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dts
> @@ -0,0 +1,18 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2019 Google LLC
> + *
> + * Device-tree for Krane sku176.
> + *
> + * SKU is a 8-bit value (0xb0 == 176):
> + * - Bits 7..4: Panel ID: 0xb (BOE)
> + * - Bits 3..0: SKU ID: 0x0 (default)
> + */
> +
> +/dts-v1/;
> +#include "mt8183-kukui-krane.dtsi"
> +
> +/ {
> + model = "MediaTek krane sku176 board";
> + compatible = "google,krane-sku176", "google,krane", "mediatek,mt8183";
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi
> new file mode 100644
> index 0..fbc471ccf805f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi
> @@ -0,0 +1,343 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2019 Google LLC
> + */
> +
> +#include "mt8183-kukui.dtsi"
> +
> +/ {
> + ppvarn_lcd: ppvarn-lcd {
> + compatible = "regulator-fixed";
> + regulator-name = "ppvarn_lcd";
> + pinctrl-names = "default";
> + pinctrl-0 = <_lcd_en>;
> +
> + enable-active-high;
> +
> + gpio = < 66 GPIO_ACTIVE_HIGH>;
> + };
> +
> + ppvarp_lcd: ppvarp-lcd {
> + compatible = "regulator-fixed";
> + regulator-name = "ppvarp_lcd";
> + pinctrl-names = "default";
> + pinctrl-0 = <_lcd_en>;
> +
> + enable-active-high;
> +
> + gpio = < 166 GPIO_ACTIVE_HIGH>;
> + };
> +
> + pp1800_lcd: pp1800-lcd {
> + compatible = "regulator-fixed";
> + regulator-name = "pp1800_lcd";
> + pinctrl-names = "default";
> + pinctrl-0 = <_lcd_en>;
> +
> + enable-active-high;
> +
> + gpio = < 36 GPIO_ACTIVE_HIGH>;
> + };
> +};
> +
> + {
> + firmware-name = "nvm_00440302_i2s_eu.bin";
> +};
> +
> + {
> + status = "okay";
> +
> + touchscreen4: touchscreen@5d {
> + compatible = "hid-over-i2c";
> + reg = <0x5d>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_touch>;
> +
> + interrupt-parent = <>;
> + interrupts = <155 IRQ_TYPE_EDGE_FALLING>;
> +
> + post-power-on-delay-ms = <10>;
> + hid-descr-addr = <0x0001>;
> + };
> +};
> +
> +_vcama2_reg {
> + regulator-min-microvolt = <280>;
> + regulator-max-microvolt = <280>;
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + status = "okay";
> + clock-frequency = <40>;
> +
> + eeprom@58 {
> + compatible = "atmel,24c32";
> + reg = <0x58>;
> + pagesize = <32>;
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
Re: [PATCH v2 6/7] arm64: dts: mt8183: Add USB3.0 support
On Thu, Jun 25, 2020 at 6:18 PM Enric Balletbo i Serra
wrote:
>
> Add the USB3.0 phyter and controller for the MediaTek's MT8183 SoC.
>
> Signed-off-by: Enric Balletbo i Serra
Tested-by: Hsin-Yi Wang
> ---
>
> Changes in v2:
> - Move adding #phy-cells to this patch. (Matthias Brugger)
>
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 58
> 1 file changed, 58 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 6c00ffa275202..102105871db25 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
> #include "mt8183-pinfunc.h"
>
> / {
> @@ -648,6 +649,36 @@ i2c8: i2c@1101b000 {
> status = "disabled";
> };
>
> + ssusb: usb@11201000 {
> + compatible ="mediatek,mt8183-mtu3", "mediatek,mtu3";
> + reg = <0 0x11201000 0 0x2e00>,
> + <0 0x11203e00 0 0x0100>;
> + reg-names = "mac", "ippc";
> + interrupts = ;
> + phys = < PHY_TYPE_USB2>,
> + < PHY_TYPE_USB3>;
> + clocks = < CLK_INFRA_UNIPRO_SCK>,
> +< CLK_INFRA_USB>;
> + clock-names = "sys_ck", "ref_ck";
> + mediatek,syscon-wakeup = < 0x400 0>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + status = "disabled";
> +
> + usb_host: xhci@1120 {
> + compatible = "mediatek,mt8183-xhci",
> +"mediatek,mtk-xhci";
> + reg = <0 0x1120 0 0x1000>;
> + reg-names = "mac";
> + interrupts = ;
> + clocks = < CLK_INFRA_UNIPRO_SCK>,
> +< CLK_INFRA_USB>;
> + clock-names = "sys_ck", "ref_ck";
> + status = "disabled";
> + };
> + };
> +
> audiosys: syscon@1122 {
> compatible = "mediatek,mt8183-audiosys", "syscon";
> reg = <0 0x1122 0 0x1000>;
> @@ -684,6 +715,33 @@ efuse: efuse@11f1 {
> reg = <0 0x11f1 0 0x1000>;
> };
>
> + u3phy: usb-phy@11f4 {
> + compatible = "mediatek,mt8183-tphy",
> +"mediatek,generic-tphy-v2";
> + #address-cells = <1>;
> + #phy-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0 0x11f4 0x1000>;
> + status = "okay";
> +
> + u2port0: usb-phy@0 {
> + reg = <0x0 0x700>;
> + clocks = <>;
> + clock-names = "ref";
> + #phy-cells = <1>;
> + mediatek,discth = <15>;
> + status = "okay";
> + };
> +
> + u3port0: usb-phy@0700 {
> + reg = <0x0700 0x900>;
> + clocks = <>;
> + clock-names = "ref";
> + #phy-cells = <1>;
> + status = "okay";
> + };
> + };
> +
> mfgcfg: syscon@1300 {
> compatible = "mediatek,mt8183-mfgcfg", "syscon";
> reg = <0 0x1300 0 0x1000>;
> --
> 2.27.0
>
Re: [PATCH v4 12/37] PM / devfreq: tegra20: Use MC timings for building OPP table
02.07.2020 07:18, Chanwoo Choi пишет:
> Hi Dmitry,
>
> On 6/9/20 10:13 PM, Dmitry Osipenko wrote:
>> The clk_round_rate() won't be usable for building OPP table once
>> interconnect support will be added to the EMC driver because that CLK API
>> function limits the rounded rate based on the clk rate that is imposed by
>> active clk-users, and thus, the rounding won't work as expected if
>> interconnect will set the minimum EMC clock rate before devfreq driver is
>> loaded. The struct tegra_mc contains memory timings which could be used by
>> the devfreq driver for building up OPP table instead of rounding clock
>> rate, this patch implements this idea.
>>
>> Signed-off-by: Dmitry Osipenko
>> ---
>> drivers/devfreq/tegra20-devfreq.c | 18 +++---
>> 1 file changed, 11 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/devfreq/tegra20-devfreq.c
>> b/drivers/devfreq/tegra20-devfreq.c
>> index 6469dc69c5e0..bf504ca4dea2 100644
>> --- a/drivers/devfreq/tegra20-devfreq.c
>> +++ b/drivers/devfreq/tegra20-devfreq.c
>> @@ -123,8 +123,7 @@ static int tegra_devfreq_probe(struct platform_device
>> *pdev)
>> {
>> struct tegra_devfreq *tegra;
>> struct tegra_mc *mc;
>> -unsigned long max_rate;
>> -unsigned long rate;
>> +unsigned int i;
>> int err;
>>
>> mc = tegra_get_memory_controller();
>> @@ -151,12 +150,17 @@ static int tegra_devfreq_probe(struct platform_device
>> *pdev)
>>
>> tegra->regs = mc->regs;
>>
>> -max_rate = clk_round_rate(tegra->emc_clock, ULONG_MAX);
>> -
>> -for (rate = 0; rate <= max_rate; rate++) {
>> -rate = clk_round_rate(tegra->emc_clock, rate);
>> +if (!mc->num_timings) {
>
> Could you explain what is meaning of 'num_timing?
The num_timings is the number of memory timings defined in a
device-tree. One timing configuration per memory clock rate.
> Also, why add the opp entry in case of mc->num_timings is zero?
Timings may be not defined in some device-trees at all and in this case
memory always running on a fixed clock rate.
The devfreq driver won't be practically useful if mc->num_timings is
zero since memory frequency can't be changed, but anyways we'd want to
load the devfreq driver in order to prevent confusion about why it's not
loaded.
For example, you may ask somebody to show contents of
/sys/class/devfreq/tegra20-devfreq/trans_stat and the person says to you
that this file doesn't exist, now you'll have to figure out what
happened to the devfreq driver.
Re: [PATCH v2 3/7] arm64: dts: mt8183: Add MediaTek's peripheral configuration controller
On Thu, Jun 25, 2020 at 6:18 PM Enric Balletbo i Serra
wrote:
>
> The MediaTek's peripheral configuration controller is present on the
> MT8183 SoC. Add the node for that controller.
>
> Signed-off-by: Enric Balletbo i Serra
Tested-by: Hsin-Yi Wang
> ---
>
> Changes in v2: None
>
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 1e03c849dc5d6..00137ec61164d 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -285,6 +285,12 @@ infracfg: syscon@10001000 {
> #reset-cells = <1>;
> };
>
> + pericfg: syscon@10003000 {
> + compatible = "mediatek,mt8183-pericfg", "syscon";
> + reg = <0 0x10003000 0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> pio: pinctrl@10005000 {
> compatible = "mediatek,mt8183-pinctrl";
> reg = <0 0x10005000 0 0x1000>,
> --
> 2.27.0
>
Re: [PATCH v2 5/7] arm64: dts: mt8183-evb: Fix unit name warnings
On Thu, Jun 25, 2020 at 6:18 PM Enric Balletbo i Serra
wrote:
>
> Remove the unit address from the DT nodes that doesn't have a reg
> property. This fixes the following unit name warnings:
>
> Warning (unit_address_vs_reg): /soc/pinctrl@10005000/mmc0@0: node has a
> unit name, but no reg or ranges property
> Warning (unit_address_vs_reg): /soc/pinctrl@10005000/mmc1@0: node has a
> unit name, but no reg or ranges property
>
> Signed-off-by: Enric Balletbo i Serra
Tested-by: Hsin-Yi Wang
> ---
>
> Changes in v2: None
>
> arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> index afd6ddbcbdf2c..ae405bd8f06b0 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> @@ -205,7 +205,7 @@ pins_rst {
> };
> };
>
> - mmc0_pins_uhs: mmc0@0{
> + mmc0_pins_uhs: mmc0 {
> pins_cmd_dat {
> pinmux = ,
> ,
> @@ -264,7 +264,7 @@ pins_pmu {
> };
> };
>
> - mmc1_pins_uhs: mmc1@0{
> + mmc1_pins_uhs: mmc1 {
> pins_cmd_dat {
> pinmux = ,
>,
> --
> 2.27.0
>
Re: [PATCH v2 4/7] arm64: dts: mt8183: Fix unit name warnings
On Thu, Jun 25, 2020 at 6:18 PM Enric Balletbo i Serra
wrote:
>
> Remove the unit address from the DT nodes that doesn't have a reg
> property. This fixes the following unit name warnings:
>
> Warning (unit_address_vs_reg): /cpus/idle-states/cluster-sleep@0: node has
> a unit name, but no reg or ranges property
> Warning (unit_address_vs_reg): /cpus/idle-states/cluster-sleep@1: node has
> a unit name, but no reg or ranges property
>
> Signed-off-by: Enric Balletbo i Serra
Tested-by: Hsin-Yi Wang
> ---
>
> Changes in v2:
> - Replace cluster-sleepX for cluster-sleep-x (Matthias Brugger)
>
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 00137ec61164d..6c00ffa275202 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -168,7 +168,7 @@ CPU_SLEEP: cpu-sleep {
> min-residency-us = <800>;
> };
>
> - CLUSTER_SLEEP0: cluster-sleep@0 {
> + CLUSTER_SLEEP0: cluster-sleep-0 {
> compatible = "arm,idle-state";
> local-timer-stop;
> arm,psci-suspend-param = <0x01010001>;
> @@ -176,7 +176,7 @@ CLUSTER_SLEEP0: cluster-sleep@0 {
> exit-latency-us = <400>;
> min-residency-us = <1000>;
> };
> - CLUSTER_SLEEP1: cluster-sleep@1 {
> + CLUSTER_SLEEP1: cluster-sleep-1 {
> compatible = "arm,idle-state";
> local-timer-stop;
> arm,psci-suspend-param = <0x01010001>;
> --
> 2.27.0
>
Re: [PATCH v2 2/7] arm64: dts: mt6358: Add the compatible for the regulators
On Thu, Jun 25, 2020 at 6:18 PM Enric Balletbo i Serra
wrote:
>
> The regulators are expected to be instantiated with matching the
> device-tree compatible, so add the proper compatible name under the
> regulators node.
>
> Signed-off-by: Enric Balletbo i Serra
Tested-by: Hsin-Yi Wang
> ---
>
> Changes in v2: None
>
> arch/arm64/boot/dts/mediatek/mt6358.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt6358.dtsi
> b/arch/arm64/boot/dts/mediatek/mt6358.dtsi
> index 9361ada0c497e..fa159b20379e4 100644
> --- a/arch/arm64/boot/dts/mediatek/mt6358.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt6358.dtsi
> @@ -16,6 +16,8 @@ mt6358codec: mt6358codec {
> };
>
> mt6358regulator: mt6358regulator {
> + compatible = "mediatek,mt6358-regulator";
> +
> mt6358_vdram1_reg: buck_vdram1 {
> regulator-name = "vdram1";
> regulator-min-microvolt = <50>;
> --
> 2.27.0
>
Re: [RFC][PATCH 3/8] mm/vmscan: Attempt to migrate page in lieu of discard
David Rientjes writes: > On Wed, 1 Jul 2020, Dave Hansen wrote: > >> > Could this cause us to break a user's mbind() or allow a user to >> > circumvent their cpuset.mems? >> >> In its current form, yes. >> >> My current rationale for this is that while it's not as deferential as >> it can be to the user/kernel ABI contract, it's good *overall* behavior. >> The auto-migration only kicks in when the data is about to go away. So >> while the user's data might be slower than they like, it is *WAY* faster >> than they deserve because it should be off on the disk. >> > > It's outside the scope of this patchset, but eventually there will be a > promotion path that I think requires a strict 1:1 relationship between > DRAM and PMEM nodes because otherwise mbind(), set_mempolicy(), and > cpuset.mems become ineffective for nodes facing memory pressure. I have posted an patchset for AutoNUMA based promotion support, https://lore.kernel.org/lkml/20200218082634.1596727-1-ying.hu...@intel.com/ Where, the page is promoted upon NUMA hint page fault. So all memory policy (mbind(), set_mempolicy(), and cpuset.mems) are available. We can refuse promoting the page to the DRAM nodes that are not allowed by any memory policy. So, 1:1 relationship isn't necessary for promotion. > For the purposes of this patchset, agreed that DRAM -> PMEM -> swap makes > perfect sense. Theoretically, I think you could have DRAM N0 and N1 and > then a single PMEM N2 and this N2 can be the terminal node for both N0 and > N1. On promotion, I think we need to rely on something stronger than > autonuma to decide which DRAM node to promote to: specifically any user > policy put into effect (memory tiering or autonuma shouldn't be allowed to > subvert these user policies). > > As others have mentioned, we lose the allocation or process context at the > time of demotion or promotion As above, we have process context at time of promotion. > and any workaround for that requires some > hacks, such as mapping the page to cpuset (what is the right solution for > shared pages?) or adding NUMA locality handling to memcg. It sounds natural to me to add NUMA nodes restriction to memcg. Best Regards, Huang, Ying
[PATCH 2/2] staging: rtl8188eu: include: rtw_pwrctrl.h: fixed a blank space coding style issue.
add blank spaces to improve code readability.
Signed-off-by: B K Karthik
---
drivers/staging/rtl8188eu/include/rtw_pwrctrl.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/include/rtw_pwrctrl.h
b/drivers/staging/rtl8188eu/include/rtw_pwrctrl.h
index c89328142731..b4cf0f1ce6d3 100644
--- a/drivers/staging/rtl8188eu/include/rtw_pwrctrl.h
+++ b/drivers/staging/rtl8188eu/include/rtw_pwrctrl.h
@@ -84,7 +84,7 @@ struct reportpwrstate_parm {
unsigned short rsvd;
};
-#define LPS_DELAY_TIME (1*HZ) /* 1 sec */
+#define LPS_DELAY_TIME (1 * HZ) /* 1 sec */
#define EXE_PWR_NONE 0x01
#define EXE_PWR_IPS0x02
--
2.20.1
signature.asc
Description: PGP signature
[PATCH 1/2] staging: rtl8188eu: include: rtw_pwrctrl.h: fixed multiple parentheses coding style issues.
add parentheses since complex valued macros must be enclosed within parentheses.
Signed-off-by: B K Karthik
---
drivers/staging/rtl8188eu/include/rtw_pwrctrl.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8188eu/include/rtw_pwrctrl.h
b/drivers/staging/rtl8188eu/include/rtw_pwrctrl.h
index 404634999e35..c89328142731 100644
--- a/drivers/staging/rtl8188eu/include/rtw_pwrctrl.h
+++ b/drivers/staging/rtl8188eu/include/rtw_pwrctrl.h
@@ -84,7 +84,7 @@ struct reportpwrstate_parm {
unsigned short rsvd;
};
-#define LPS_DELAY_TIME 1*HZ /* 1 sec */
+#define LPS_DELAY_TIME (1*HZ) /* 1 sec */
#define EXE_PWR_NONE 0x01
#define EXE_PWR_IPS0x02
@@ -201,7 +201,7 @@ struct pwrctrl_priv {
};
#define rtw_get_ips_mode_req(pwrctrlpriv) \
- (pwrctrlpriv)->ips_mode_req
+ ((pwrctrlpriv)->ips_mode_req)
#define rtw_ips_mode_req(pwrctrlpriv, ips_mode) \
((pwrctrlpriv)->ips_mode_req = (ips_mode))
--
2.20.1
signature.asc
Description: PGP signature
Re: exfatprogs-1.0.3 version released
Hello Sedat, For v1.0.3 and later releases, we can provide tar.xz tarballs, hashes and detached signatures. But is there a reason why hashes are required despite the signature? We will let you know when it's done. Thanks. Regards, Hyunchul 2020년 6월 30일 (화) 오후 7:16, Sedat Dilek 님이 작성: > > On Tue, May 12, 2020 at 10:17 AM Namjae Jeon wrote: > > > > Hi folk, > > > > We have released exfatprogs-1.0.3 version. > > Any feedback is welcome!:) > > > > CHANGES : > > * Rename label.exfat to tune.exfat. > > * tune.exfat: change argument style(-l option for print level, > >-L option for setting label) > > * mkfs.exfat: harmonize set volume label option with tune.exfat. > > > > NEW FEATURES : > > * Add man page. > > > > BUG FIXES : > > * Fix the reported build warnings/errors. > > * Add memset to clean garbage in allocation. > > * Fix wrong volume label array size. > > * Open a device using O_EXCL to avoid formatting it while it is mounted. > > * Fix incomplete "make dist" generated tarball. > > > > The git tree is at: > > https://github.com/exfatprogs/exfatprogs > > > > The tarballs can be found at: > > > > https://github.com/exfatprogs/exfatprogs/releases/download/1.0.3/exfatprogs-1.0.3.tar.gz > > > > Hi, > > thanks for the upgrade. > > Today, I contacted the Debian maintainer on how he wants to > distinguish between exfat-utils vs. exfatprogs as Linux v5.7 entered > Debian/unstable. > > When I looked at the release/tags page on github: > > Can you please offer tar.xz tarballs, please? > Hashes? Like sha256sum > Signing keys? (Signed tarballs?) > > Thanks. > > Regards, > - Sedat -
[PATCH] staging: rtl8188eu: include: rtl8188e_xmit.h: fixed multiple blank space coding style issues
added blank spaces to improve code readability. (coding style issue)
Signed-off-by: B K Karthik
---
drivers/staging/rtl8188eu/include/rtl8188e_xmit.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8188eu/include/rtl8188e_xmit.h
b/drivers/staging/rtl8188eu/include/rtl8188e_xmit.h
index 49884cceb349..c115007d883d 100644
--- a/drivers/staging/rtl8188eu/include/rtl8188e_xmit.h
+++ b/drivers/staging/rtl8188eu/include/rtl8188e_xmit.h
@@ -30,11 +30,11 @@
#define SET_EARLYMODE_LEN2_1(__pAddr, __Value) \
SET_BITS_TO_LE_4BYTE(__pAddr, 28, 4, __Value)
#define SET_EARLYMODE_LEN2_2(__pAddr, __Value) \
- SET_BITS_TO_LE_4BYTE(__pAddr+4, 0, 8, __Value)
+ SET_BITS_TO_LE_4BYTE(__pAddr + 4, 0, 8, __Value)
#define SET_EARLYMODE_LEN3(__pAddr, __Value) \
- SET_BITS_TO_LE_4BYTE(__pAddr+4, 8, 12, __Value)
+ SET_BITS_TO_LE_4BYTE(__pAddr + 4, 8, 12, __Value)
#define SET_EARLYMODE_LEN4(__pAddr, __Value) \
- SET_BITS_TO_LE_4BYTE(__pAddr+4, 20, 12, __Value)
+ SET_BITS_TO_LE_4BYTE(__pAddr + 4, 20, 12, __Value)
/* */
/* defined for TX DESC Operation */
@@ -100,7 +100,7 @@ enum TXDESC_SC {
#define txdesc_set_ccx_sw_88e(txdesc, value) \
do { \
- ((struct txdesc_88e *)(txdesc))->sw1 = (((value)>>8) & 0x0f); \
+ ((struct txdesc_88e *)(txdesc))->sw1 = (((value) >> 8) & 0x0f);
\
((struct txdesc_88e *)(txdesc))->sw0 = ((value) & 0xff); \
} while (0)
@@ -138,9 +138,9 @@ struct txrpt_ccx_88e {
u8 sw0;
};
-#define txrpt_ccx_sw_88e(txrpt_ccx) ((txrpt_ccx)->sw0 + ((txrpt_ccx)->sw1<<8))
+#define txrpt_ccx_sw_88e(txrpt_ccx) ((txrpt_ccx)->sw0 + ((txrpt_ccx)->sw1 <<
8))
#define txrpt_ccx_qtime_88e(txrpt_ccx) \
- ((txrpt_ccx)->ccx_qtime0+((txrpt_ccx)->ccx_qtime1<<8))
+ ((txrpt_ccx)->ccx_qtime0+((txrpt_ccx)->ccx_qtime1 << 8))
void rtl8188e_fill_fake_txdesc(struct adapter *padapter, u8 *pDesc,
u32 BufferLen, u8 IsPsPoll, u8 IsBTQosNull);
--
2.20.1
signature.asc
Description: PGP signature
[PATCH] staging: rtl8188eu: include: rtw_recv.h: fixed a blank space coding style issue.
added blank spaces to improve code readability. Signed-off-by: B K Karthik --- drivers/staging/rtl8188eu/include/rtw_recv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8188eu/include/rtw_recv.h b/drivers/staging/rtl8188eu/include/rtw_recv.h index e383cb119e1b..b281b9e7fcea 100644 --- a/drivers/staging/rtl8188eu/include/rtw_recv.h +++ b/drivers/staging/rtl8188eu/include/rtw_recv.h @@ -13,7 +13,7 @@ #define NR_RECVFRAME 256 #define RXFRAME_ALIGN 8 -#define RXFRAME_ALIGN_SZ (1< signature.asc Description: PGP signature
Re: [PATCH] staging: rtl8188eu: include: rtl8188e_xmit.h: fixed multiple blank space coding style issues
On Thu, Jul 02, 2020 at 12:48:42AM -0400, B K Karthik wrote:
> added blank spaces to improve code readability.
>
> Signed-off-by: B K Karthik
> ---
> drivers/staging/rtl8188eu/include/rtl8188e_xmit.h | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/rtl8188eu/include/rtl8188e_xmit.h
> b/drivers/staging/rtl8188eu/include/rtl8188e_xmit.h
> index 49884cceb349..c115007d883d 100644
> --- a/drivers/staging/rtl8188eu/include/rtl8188e_xmit.h
> +++ b/drivers/staging/rtl8188eu/include/rtl8188e_xmit.h
> @@ -30,11 +30,11 @@
> #define SET_EARLYMODE_LEN2_1(__pAddr, __Value) \
> SET_BITS_TO_LE_4BYTE(__pAddr, 28, 4, __Value)
> #define SET_EARLYMODE_LEN2_2(__pAddr, __Value) \
> - SET_BITS_TO_LE_4BYTE(__pAddr+4, 0, 8, __Value)
> + SET_BITS_TO_LE_4BYTE(__pAdd r +4, 0, 8, __Value)
^
did this get compile tested? :)
-Kees
> #define SET_EARLYMODE_LEN3(__pAddr, __Value) \
> - SET_BITS_TO_LE_4BYTE(__pAddr+4, 8, 12, __Value)
> + SET_BITS_TO_LE_4BYTE(__pAddr + 4, 8, 12, __Value)
> #define SET_EARLYMODE_LEN4(__pAddr, __Value) \
> - SET_BITS_TO_LE_4BYTE(__pAddr+4, 20, 12, __Value)
> + SET_BITS_TO_LE_4BYTE(__pAddr + 4, 20, 12, __Value)
>
> /* */
> /* defined for TX DESC Operation */
> @@ -100,7 +100,7 @@ enum TXDESC_SC {
>
> #define txdesc_set_ccx_sw_88e(txdesc, value) \
> do { \
> - ((struct txdesc_88e *)(txdesc))->sw1 = (((value)>>8) & 0x0f); \
> + ((struct txdesc_88e *)(txdesc))->sw1 = (((value) >> 8) & 0x0f);
> \
> ((struct txdesc_88e *)(txdesc))->sw0 = ((value) & 0xff); \
> } while (0)
>
> @@ -138,9 +138,9 @@ struct txrpt_ccx_88e {
> u8 sw0;
> };
>
> -#define txrpt_ccx_sw_88e(txrpt_ccx) ((txrpt_ccx)->sw0 +
> ((txrpt_ccx)->sw1<<8))
> +#define txrpt_ccx_sw_88e(txrpt_ccx) ((txrpt_ccx)->sw0 + ((txrpt_ccx)->sw1 <<
> 8))
> #define txrpt_ccx_qtime_88e(txrpt_ccx) \
> - ((txrpt_ccx)->ccx_qtime0+((txrpt_ccx)->ccx_qtime1<<8))
> + ((txrpt_ccx)->ccx_qtime0+((txrpt_ccx)->ccx_qtime1 << 8))
>
> void rtl8188e_fill_fake_txdesc(struct adapter *padapter, u8 *pDesc,
> u32 BufferLen, u8 IsPsPoll, u8 IsBTQosNull);
> --
> 2.20.1
>
--
Kees Cook
[PATCH 2/2] staging: rtl8188eu: include: rtw_pwrctrl.h: fixed a blank space coding style issue.
add blank spaces to improve code readability.
Signed-off-by: B K Karthik
---
drivers/staging/rtl8188eu/include/rtw_pwrctrl.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/include/rtw_pwrctrl.h
b/drivers/staging/rtl8188eu/include/rtw_pwrctrl.h
index c89328142731..b4cf0f1ce6d3 100644
--- a/drivers/staging/rtl8188eu/include/rtw_pwrctrl.h
+++ b/drivers/staging/rtl8188eu/include/rtw_pwrctrl.h
@@ -84,7 +84,7 @@ struct reportpwrstate_parm {
unsigned short rsvd;
};
-#define LPS_DELAY_TIME (1*HZ) /* 1 sec */
+#define LPS_DELAY_TIME (1 * HZ) /* 1 sec */
#define EXE_PWR_NONE 0x01
#define EXE_PWR_IPS0x02
--
2.20.1
signature.asc
Description: PGP signature
[PATCH 1/2] staging: rtl8188eu: include: rtw_pwrctrl.h: fixed multiple parentheses coding style issues.
add parentheses since complex valued macros must be enclosed within parentheses.
Signed-off-by: B K Karthik
---
drivers/staging/rtl8188eu/include/rtw_pwrctrl.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8188eu/include/rtw_pwrctrl.h
b/drivers/staging/rtl8188eu/include/rtw_pwrctrl.h
index 404634999e35..c89328142731 100644
--- a/drivers/staging/rtl8188eu/include/rtw_pwrctrl.h
+++ b/drivers/staging/rtl8188eu/include/rtw_pwrctrl.h
@@ -84,7 +84,7 @@ struct reportpwrstate_parm {
unsigned short rsvd;
};
-#define LPS_DELAY_TIME 1*HZ /* 1 sec */
+#define LPS_DELAY_TIME (i*HZ) /* 1 sec */
#define EXE_PWR_NONE 0x01
#define EXE_PWR_IPS0x02
@@ -201,7 +201,7 @@ struct pwrctrl_priv {
};
#define rtw_get_ips_mode_req(pwrctrlpriv) \
- (pwrctrlpriv)->ips_mode_req
+ ((pwrctrlpriv)->ips_mode_req)
#define rtw_ips_mode_req(pwrctrlpriv, ips_mode) \
((pwrctrlpriv)->ips_mode_req = (ips_mode))
--
2.20.1
signature.asc
Description: PGP signature
[PATCH] staging: rtl8188eu: include: rtw_cmd.h: fixed a blank space coding style issue.
add blank spaces for improved code readability.
Signed-off-by: B K Karthik
---
drivers/staging/rtl8188eu/include/rtw_cmd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/include/rtw_cmd.h
b/drivers/staging/rtl8188eu/include/rtw_cmd.h
index fa5e212fc9e0..002a797c6d0a 100644
--- a/drivers/staging/rtl8188eu/include/rtw_cmd.h
+++ b/drivers/staging/rtl8188eu/include/rtw_cmd.h
@@ -115,7 +115,7 @@ struct setopmode_parm {
*/
#define RTW_SSID_SCAN_AMOUNT 9 /* for WEXT_CSCAN_AMOUNT 9 */
-#define RTW_CHANNEL_SCAN_AMOUNT (14+37)
+#define RTW_CHANNEL_SCAN_AMOUNT (14 + 37)
struct sitesurvey_parm {
int scan_mode; /* active: 1, passive: 0 */
u8 ssid_num;
--
2.20.1
signature.asc
Description: PGP signature
[PATCH] staging: rtl8188eu: include: rtl8188e_xmit.h: fixed multiple blank space coding style issues
added blank spaces to improve code readability.
Signed-off-by: B K Karthik
---
drivers/staging/rtl8188eu/include/rtl8188e_xmit.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8188eu/include/rtl8188e_xmit.h
b/drivers/staging/rtl8188eu/include/rtl8188e_xmit.h
index 49884cceb349..c115007d883d 100644
--- a/drivers/staging/rtl8188eu/include/rtl8188e_xmit.h
+++ b/drivers/staging/rtl8188eu/include/rtl8188e_xmit.h
@@ -30,11 +30,11 @@
#define SET_EARLYMODE_LEN2_1(__pAddr, __Value) \
SET_BITS_TO_LE_4BYTE(__pAddr, 28, 4, __Value)
#define SET_EARLYMODE_LEN2_2(__pAddr, __Value) \
- SET_BITS_TO_LE_4BYTE(__pAddr+4, 0, 8, __Value)
+ SET_BITS_TO_LE_4BYTE(__pAdd r +4, 0, 8, __Value)
#define SET_EARLYMODE_LEN3(__pAddr, __Value) \
- SET_BITS_TO_LE_4BYTE(__pAddr+4, 8, 12, __Value)
+ SET_BITS_TO_LE_4BYTE(__pAddr + 4, 8, 12, __Value)
#define SET_EARLYMODE_LEN4(__pAddr, __Value) \
- SET_BITS_TO_LE_4BYTE(__pAddr+4, 20, 12, __Value)
+ SET_BITS_TO_LE_4BYTE(__pAddr + 4, 20, 12, __Value)
/* */
/* defined for TX DESC Operation */
@@ -100,7 +100,7 @@ enum TXDESC_SC {
#define txdesc_set_ccx_sw_88e(txdesc, value) \
do { \
- ((struct txdesc_88e *)(txdesc))->sw1 = (((value)>>8) & 0x0f); \
+ ((struct txdesc_88e *)(txdesc))->sw1 = (((value) >> 8) & 0x0f);
\
((struct txdesc_88e *)(txdesc))->sw0 = ((value) & 0xff); \
} while (0)
@@ -138,9 +138,9 @@ struct txrpt_ccx_88e {
u8 sw0;
};
-#define txrpt_ccx_sw_88e(txrpt_ccx) ((txrpt_ccx)->sw0 + ((txrpt_ccx)->sw1<<8))
+#define txrpt_ccx_sw_88e(txrpt_ccx) ((txrpt_ccx)->sw0 + ((txrpt_ccx)->sw1 <<
8))
#define txrpt_ccx_qtime_88e(txrpt_ccx) \
- ((txrpt_ccx)->ccx_qtime0+((txrpt_ccx)->ccx_qtime1<<8))
+ ((txrpt_ccx)->ccx_qtime0+((txrpt_ccx)->ccx_qtime1 << 8))
void rtl8188e_fill_fake_txdesc(struct adapter *padapter, u8 *pDesc,
u32 BufferLen, u8 IsPsPoll, u8 IsBTQosNull);
--
2.20.1
signature.asc
Description: PGP signature
[GIT PULL] io_uring fixes for 5.8-rc4
Hi Linus, One fix in here, for a regression in 5.7 where a task is waiting in the kernel for a condition, but that condition won't become true until task_work is run. The task_work can't be run exactly because the task is waiting in the kernel, so we'll never make any progress. One example of that is registering an eventfd and queueing io_uring work, and then the task goes and waits in eventfd read with the expectation that it'll get woken (and read an event) when the io_uring request completes. The io_uring request is finished through task_work, which won't get run while the task is looping in eventfd read. Please pull! The following changes since commit d60b5fbc1ce8210759b568da49d149b868e7c6d3: io_uring: fix current->mm NULL dereference on exit (2020-06-25 07:20:43 -0600) are available in the Git repository at: git://git.kernel.dk/linux-block.git tags/io_uring-5.8-2020-07-01 for you to fetch changes up to ce593a6c480a22acba08795be313c0c6d49dd35d: io_uring: use signal based task_work running (2020-06-30 12:39:05 -0600) io_uring-5.8-2020-07-01 Jens Axboe (1): io_uring: use signal based task_work running Oleg Nesterov (1): task_work: teach task_work_add() to do signal_wake_up() fs/io_uring.c| 32 include/linux/sched/jobctl.h | 4 +++- include/linux/task_work.h| 5 - kernel/signal.c | 10 +++--- kernel/task_work.c | 16 ++-- 5 files changed, 52 insertions(+), 15 deletions(-) -- Jens Axboe
[PATCH net-next 1/4] net: Add cable test netdevice operations
In preparation for decoupling the ethtool cable test from the PHY
library, add definitions for two new network device operations:
* ndo_cable_test_start
* ndo_cable_test_tdr_start
In a subsequent patch we will start making use of those.
Signed-off-by: Florian Fainelli
---
include/linux/netdevice.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 39e28e11863c..43f640579973 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -936,6 +936,8 @@ struct dev_ifalias {
struct devlink;
struct tlsdev_ops;
+struct phy_tdr_config;
+struct netlink_ext_ack;
struct netdev_name_node {
struct hlist_node hlist;
@@ -1278,6 +1280,13 @@ struct netdev_net_notifier {
* int (*ndo_tunnel_ctl)(struct net_device *dev, struct ip_tunnel_parm *p,
* int cmd);
* Add, change, delete or get information on an IPv4 tunnel.
+ * int (*ndo_cable_test_start)(struct net_device *dev,
+ *struct netlink_ext_ack *extack);
+ * Start a cable test.
+ * int (*ndo_cable_test_tdr_start)(struct net_device *dev,
+ *struct netlink_ext_ack *extack,
+ *const struct phy_tdr_config *config);
+ * Start a raw TDR (Time Domain Reflectometry) cable test.
*/
struct net_device_ops {
int (*ndo_init)(struct net_device *dev);
@@ -1485,6 +1494,11 @@ struct net_device_ops {
struct devlink_port * (*ndo_get_devlink_port)(struct net_device *dev);
int (*ndo_tunnel_ctl)(struct net_device *dev,
struct ip_tunnel_parm *p, int
cmd);
+ int (*ndo_cable_test_start)(struct net_device *dev,
+ struct netlink_ext_ack
*exact);
+ int (*ndo_cable_test_tdr_start)(struct net_device
*dev,
+ struct
netlink_ext_ack *exact,
+ const struct
phy_tdr_config *config);
};
/**
--
2.25.1
[PATCH net-next 2/4] net: phy: Change cable test arguments to net_device
In order to untangle the ethtool/cabletest feature with the PHY library,
make the PHY library functions take a net_device argument and derive the
phy_device reference from there.
No functional changes introduced.
Signed-off-by: Florian Fainelli
---
drivers/net/phy/phy.c | 18 ++
include/linux/phy.h | 8
net/ethtool/cabletest.c | 4 ++--
3 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 56cfae950472..fbb74f37b961 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -489,12 +489,17 @@ static void phy_abort_cable_test(struct phy_device
*phydev)
phydev_err(phydev, "Error while aborting cable test");
}
-int phy_start_cable_test(struct phy_device *phydev,
+int phy_start_cable_test(struct net_device *dev,
struct netlink_ext_ack *extack)
{
- struct net_device *dev = phydev->attached_dev;
+ struct phy_device *phydev = dev->phydev;
int err = -ENOMEM;
+ if (!dev->phydev) {
+ NL_SET_ERR_MSG(extack, "Network device not attached to a PHY");
+ return -EOPNOTSUPP;
+ }
+
if (!(phydev->drv &&
phydev->drv->cable_test_start &&
phydev->drv->cable_test_get_status)) {
@@ -552,13 +557,18 @@ int phy_start_cable_test(struct phy_device *phydev,
}
EXPORT_SYMBOL(phy_start_cable_test);
-int phy_start_cable_test_tdr(struct phy_device *phydev,
+int phy_start_cable_test_tdr(struct net_device *dev,
struct netlink_ext_ack *extack,
const struct phy_tdr_config *config)
{
- struct net_device *dev = phydev->attached_dev;
+ struct phy_device *phydev = dev->phydev;
int err = -ENOMEM;
+ if (!dev->phydev) {
+ NL_SET_ERR_MSG(extack, "Network device not attached to a PHY");
+ return -EOPNOTSUPP;
+ }
+
if (!(phydev->drv &&
phydev->drv->cable_test_tdr_start &&
phydev->drv->cable_test_get_status)) {
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 101a48fa6750..53b95c52869d 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1266,21 +1266,21 @@ int phy_restart_aneg(struct phy_device *phydev);
int phy_reset_after_clk_enable(struct phy_device *phydev);
#if IS_ENABLED(CONFIG_PHYLIB)
-int phy_start_cable_test(struct phy_device *phydev,
+int phy_start_cable_test(struct net_device *dev,
struct netlink_ext_ack *extack);
-int phy_start_cable_test_tdr(struct phy_device *phydev,
+int phy_start_cable_test_tdr(struct net_device *dev,
struct netlink_ext_ack *extack,
const struct phy_tdr_config *config);
#else
static inline
-int phy_start_cable_test(struct phy_device *phydev,
+int phy_start_cable_test(struct net_device *dev,
struct netlink_ext_ack *extack)
{
NL_SET_ERR_MSG(extack, "Kernel not compiled with PHYLIB support");
return -EOPNOTSUPP;
}
static inline
-int phy_start_cable_test_tdr(struct phy_device *phydev,
+int phy_start_cable_test_tdr(struct net_device *dev,
struct netlink_ext_ack *extack,
const struct phy_tdr_config *config)
{
diff --git a/net/ethtool/cabletest.c b/net/ethtool/cabletest.c
index 7194956aa09e..0d940a91493b 100644
--- a/net/ethtool/cabletest.c
+++ b/net/ethtool/cabletest.c
@@ -85,7 +85,7 @@ int ethnl_act_cable_test(struct sk_buff *skb, struct
genl_info *info)
if (ret < 0)
goto out_rtnl;
- ret = phy_start_cable_test(dev->phydev, info->extack);
+ ret = phy_start_cable_test(dev, info->extack);
ethnl_ops_complete(dev);
@@ -341,7 +341,7 @@ int ethnl_act_cable_test_tdr(struct sk_buff *skb, struct
genl_info *info)
if (ret < 0)
goto out_rtnl;
- ret = phy_start_cable_test_tdr(dev->phydev, info->extack, );
+ ret = phy_start_cable_test_tdr(dev, info->extack, );
ethnl_ops_complete(dev);
--
2.25.1
[PATCH net-next 0/4] net: ethtool: Untangle PHYLIB dependency
Hi all, This patch series untangles the ethtool netlink dependency with PHYLIB which exists because the cable test feature calls directly into PHY library functions. The approach taken here is to utilize a new set of net_device_ops function pointers which are automatically set to the PHY library variants when a network device driver attaches to a PHY device. Florian Fainelli (4): net: Add cable test netdevice operations net: phy: Change cable test arguments to net_device net: phy: Automatically set-up cable test netdev_ops net: ethtool: Remove PHYLIB dependency drivers/net/phy/phy.c| 18 ++ drivers/net/phy/phy_device.c | 32 include/linux/netdevice.h| 14 ++ include/linux/phy.h | 10 ++ net/Kconfig | 1 - net/ethtool/cabletest.c | 12 6 files changed, 74 insertions(+), 13 deletions(-) -- 2.25.1
[PATCH net-next 4/4] net: ethtool: Remove PHYLIB dependency
Now that we have converted the ethtool/cabletest code to use netdev_ops,
we can remove the PHY library dependency since the function pointers
will now be provided upon PHY attachment to the network device.
Signed-off-by: Florian Fainelli
---
net/Kconfig | 1 -
net/ethtool/cabletest.c | 12
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/Kconfig b/net/Kconfig
index d1672280d6a4..3831206977a1 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -455,7 +455,6 @@ config FAILOVER
config ETHTOOL_NETLINK
bool "Netlink interface for ethtool"
default y
- depends on PHYLIB=y || PHYLIB=n
help
An alternative userspace interface for ethtool based on generic
netlink. It provides better extensibility and some new features,
diff --git a/net/ethtool/cabletest.c b/net/ethtool/cabletest.c
index 0d940a91493b..d8e2eb427613 100644
--- a/net/ethtool/cabletest.c
+++ b/net/ethtool/cabletest.c
@@ -58,6 +58,7 @@ int ethnl_act_cable_test(struct sk_buff *skb, struct
genl_info *info)
{
struct nlattr *tb[ETHTOOL_A_CABLE_TEST_MAX + 1];
struct ethnl_req_info req_info = {};
+ const struct net_device_ops *ops;
struct net_device *dev;
int ret;
@@ -75,7 +76,8 @@ int ethnl_act_cable_test(struct sk_buff *skb, struct
genl_info *info)
return ret;
dev = req_info.dev;
- if (!dev->phydev) {
+ ops = dev->netdev_ops;
+ if (!ops->ndo_cable_test_start) {
ret = -EOPNOTSUPP;
goto out_dev_put;
}
@@ -85,7 +87,7 @@ int ethnl_act_cable_test(struct sk_buff *skb, struct
genl_info *info)
if (ret < 0)
goto out_rtnl;
- ret = phy_start_cable_test(dev, info->extack);
+ ret = ops->ndo_cable_test_start(dev, info->extack);
ethnl_ops_complete(dev);
@@ -308,6 +310,7 @@ int ethnl_act_cable_test_tdr(struct sk_buff *skb, struct
genl_info *info)
{
struct nlattr *tb[ETHTOOL_A_CABLE_TEST_TDR_MAX + 1];
struct ethnl_req_info req_info = {};
+ const struct net_device_ops *ops;
struct phy_tdr_config cfg;
struct net_device *dev;
int ret;
@@ -326,7 +329,8 @@ int ethnl_act_cable_test_tdr(struct sk_buff *skb, struct
genl_info *info)
return ret;
dev = req_info.dev;
- if (!dev->phydev) {
+ ops = dev->netdev_ops;
+ if (!ops->ndo_cable_test_tdr_start) {
ret = -EOPNOTSUPP;
goto out_dev_put;
}
@@ -341,7 +345,7 @@ int ethnl_act_cable_test_tdr(struct sk_buff *skb, struct
genl_info *info)
if (ret < 0)
goto out_rtnl;
- ret = phy_start_cable_test_tdr(dev, info->extack, );
+ ret = ops->ndo_cable_test_tdr_start(dev, info->extack, );
ethnl_ops_complete(dev);
--
2.25.1
[PATCH net-next 3/4] net: phy: Automatically set-up cable test netdev_ops
Upon attach, override the net_device operations with the PHY library
cable test operations and conversely, upon detach, revert to the
original net_device operations.
This will allows us in a subsequent patch to finally decouple the
ethtool/cabletest from the PHY library hard depenencies.
Signed-off-by: Florian Fainelli
---
drivers/net/phy/phy_device.c | 32
include/linux/phy.h | 2 ++
2 files changed, 34 insertions(+)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index eb1068a77ce1..100d85541a06 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1246,6 +1246,36 @@ phy_standalone_show(struct device *dev, struct
device_attribute *attr,
}
static DEVICE_ATTR_RO(phy_standalone);
+static int phy_setup_netdev_ops(struct net_device *dev)
+{
+ struct phy_device *phydev = dev->phydev;
+ struct net_device_ops *ops;
+
+ ops = devm_kzalloc(>mdio.dev, sizeof(*ops), GFP_KERNEL);
+ if (!ops)
+ return -ENOMEM;
+
+ phydev->orig_ndo_ops = dev->netdev_ops;
+ if (phydev->orig_ndo_ops)
+ memcpy(ops, phydev->orig_ndo_ops, sizeof(*ops));
+
+ ops->ndo_cable_test_start = phy_start_cable_test;
+ ops->ndo_cable_test_tdr_start = phy_start_cable_test_tdr;
+
+ dev->netdev_ops = ops;
+
+ return 0;
+}
+
+static void phy_teardown_netdev_ops(struct net_device *dev)
+{
+ struct phy_device *phydev = dev->phydev;
+
+ if (phydev->orig_ndo_ops)
+ dev->netdev_ops = phydev->orig_ndo_ops;
+ phydev->orig_ndo_ops = NULL;
+}
+
/**
* phy_sfp_attach - attach the SFP bus to the PHY upstream network device
* @upstream: pointer to the phy device
@@ -1380,6 +1410,7 @@ int phy_attach_direct(struct net_device *dev, struct
phy_device *phydev,
if (dev) {
phydev->attached_dev = dev;
dev->phydev = phydev;
+ phy_setup_netdev_ops(dev);
if (phydev->sfp_bus_attached)
dev->sfp_bus = phydev->sfp_bus;
@@ -1676,6 +1707,7 @@ void phy_detach(struct phy_device *phydev)
phy_suspend(phydev);
if (dev) {
+ phy_teardown_netdev_ops(dev);
phydev->attached_dev->phydev = NULL;
phydev->attached_dev = NULL;
}
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 53b95c52869d..04e35afa43ae 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -544,6 +544,8 @@ struct phy_device {
/* MACsec management functions */
const struct macsec_ops *macsec_ops;
#endif
+ /* Original attached network device netdev_ops pointer */
+ const struct net_device_ops *orig_ndo_ops;
};
#define to_phy_device(d) container_of(to_mdio_device(d), \
struct phy_device, mdio)
--
2.25.1
Re: linux-next: umh: fix processed error when UMH_WAIT_PROC is used seems to break linux bridge on s390x (bisected)
On 2020/07/02 0:38, Luis Chamberlain wrote: > @@ -156,6 +156,18 @@ static void call_usermodehelper_exec_sync(struct > subprocess_info *sub_info) >*/ > if (KWIFEXITED(ret)) > sub_info->retval = KWEXITSTATUS(ret); > + /* > + * Do we really want to be passing the signal, or do we pass > + * a single error code for all cases? > + */ > + else if (KWIFSIGNALED(ret)) > + sub_info->retval = KWTERMSIG(ret); No, this is bad. Caller of usermode helper is unable to distinguish exit(9) and e.g. SIGKILL'ed by the OOM-killer. Please pass raw exit status value. I feel that caller of usermode helper should not use exit status value. For example, call_sbin_request_key() is checking test_bit(KEY_FLAG_USER_CONSTRUCT, >flags) || key_validate(key) < 0 condition (if usermode helper was invoked) in order to "ignore any errors from userspace if the key was instantiated". > + /* Same here */ > + else if (KWIFSTOPPED((ret))) > + sub_info->retval = KWSTOPSIG(ret); > + /* And are we really sure we want this? */ > + else if (KWIFCONTINUED((ret))) > + sub_info->retval = 0; > } > > /* Restore default kernel sig handler */ >
[PATCH v2] scsi: ufs: Cleanup completed request without interrupt notification
If somehow no interrupt notification is raised for a completed request
and its doorbell bit is cleared by host, UFS driver needs to cleanup
its outstanding bit in ufshcd_abort().
Otherwise, system may crash by below abnormal flow:
After this request is requeued by SCSI layer with its
outstanding bit set, the next completed request will trigger
ufshcd_transfer_req_compl() to handle all "completed outstanding
bits". In this time, the "abnormal outstanding bit" will be detected
and the "requeued request" will be chosen to execute request
post-processing flow. This is wrong and blk_finish_request() will
BUG_ON because this request is still "alive".
It is worth mentioning that before ufshcd_abort() cleans the timed-out
request, driver needs to check again if this request is really not
handled by __ufshcd_transfer_req_compl() yet because it is possible
that its interrupt comes very lately before the cleaning.
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufshcd.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index cadfa9006972..0f4f3255e403 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -6462,7 +6462,7 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
/* command completed already */
dev_err(hba->dev, "%s: cmd at tag %d successfully
cleared from DB.\n",
__func__, tag);
- goto out;
+ goto cleanup;
} else {
dev_err(hba->dev,
"%s: no response from device. tag = %d, err
%d\n",
@@ -6496,9 +6496,14 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
goto out;
}
+cleanup:
+ spin_lock_irqsave(host->host_lock, flags);
+ if (!test_bit(tag, hba->outstanding_reqs)) {
+ spin_unlock_irqrestore(host->host_lock, flags);
+ goto out;
+ }
scsi_dma_unmap(cmd);
- spin_lock_irqsave(host->host_lock, flags);
ufshcd_outstanding_req_clear(hba, tag);
hba->lrb[tag].cmd = NULL;
spin_unlock_irqrestore(host->host_lock, flags);
--
2.18.0
Re: [PATCH RESEND net-next v3 2/3] net: enetc: Initialize SerDes for SGMII and USXGMII protocols
Hi Michael,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Michael-Walle/net-enetc-remove-bootloader-dependency/20200702-053650
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
2b04a66156159592156a97553057e8c36de2ee70
config: x86_64-allyesconfig (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
c8f1d442d0858f66fd4128fde6f67eb5202fa2b1)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/net/ethernet/freescale/enetc/enetc_pf.c:879:2: error: implicit
>> declaration of function 'devm_mdiobus_free'
>> [-Werror,-Wimplicit-function-declaration]
devm_mdiobus_free(dev, bus);
^
1 error generated.
vim +/devm_mdiobus_free +879 drivers/net/ethernet/freescale/enetc/enetc_pf.c
835
836 static int enetc_imdio_init(struct enetc_pf *pf, bool is_c45)
837 {
838 struct device *dev = >si->pdev->dev;
839 struct enetc_mdio_priv *mdio_priv;
840 struct phy_device *pcs;
841 struct mii_bus *bus;
842 int err;
843
844 bus = devm_mdiobus_alloc_size(dev, sizeof(*mdio_priv));
845 if (!bus)
846 return -ENOMEM;
847
848 bus->name = "Freescale ENETC internal MDIO Bus";
849 bus->read = enetc_mdio_read;
850 bus->write = enetc_mdio_write;
851 bus->parent = dev;
852 bus->phy_mask = ~0;
853 mdio_priv = bus->priv;
854 mdio_priv->hw = >si->hw;
855 mdio_priv->mdio_base = ENETC_PM_IMDIO_BASE;
856 snprintf(bus->id, MII_BUS_ID_SIZE, "%s-imdio", dev_name(dev));
857
858 err = mdiobus_register(bus);
859 if (err) {
860 dev_err(dev, "cannot register internal MDIO bus
(%d)\n", err);
861 goto free_mdio_bus;
862 }
863
864 pcs = get_phy_device(bus, 0, is_c45);
865 if (IS_ERR(pcs)) {
866 err = PTR_ERR(pcs);
867 dev_err(dev, "cannot get internal PCS PHY (%d)\n", err);
868 goto unregister_mdiobus;
869 }
870
871 pf->imdio = bus;
872 pf->pcs = pcs;
873
874 return 0;
875
876 unregister_mdiobus:
877 mdiobus_unregister(bus);
878 free_mdio_bus:
> 879 devm_mdiobus_free(dev, bus);
880 return err;
881 }
882
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH v2] f2fs: add GC_URGENT_LOW mode in gc_urgent
From: Daeho Jeong
Added a new gc_urgent mode, GC_URGENT_LOW, in which mode
F2FS will lower the bar of checking idle in order to
process outstanding discard commands and GC a little bit
aggressively.
Signed-off-by: Daeho Jeong
---
Documentation/ABI/testing/sysfs-fs-f2fs | 4 +++-
fs/f2fs/f2fs.h | 10 --
fs/f2fs/gc.c| 6 +++---
fs/f2fs/segment.c | 4 ++--
fs/f2fs/sysfs.c | 10 +++---
5 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs
b/Documentation/ABI/testing/sysfs-fs-f2fs
index 4bb93a06d8ab..7f730c4c8df2 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -229,7 +229,9 @@ Date: August 2017
Contact: "Jaegeuk Kim"
Description: Do background GC agressively when set. When gc_urgent = 1,
background thread starts to do GC by given gc_urgent_sleep_time
- interval. It is set to 0 by default.
+ interval. When gc_urgent = 2, F2FS will lower the bar of
+ checking idle in order to process outstanding discard commands
+ and GC a little bit aggressively. It is set to 0 by default.
What: /sys/fs/f2fs//gc_urgent_sleep_time
Date: August 2017
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index e6e47618a357..4b28fd42fdbc 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1283,7 +1283,8 @@ enum {
GC_NORMAL,
GC_IDLE_CB,
GC_IDLE_GREEDY,
- GC_URGENT,
+ GC_URGENT_HIGH,
+ GC_URGENT_LOW,
};
enum {
@@ -1540,6 +1541,7 @@ struct f2fs_sb_info {
unsigned int cur_victim_sec;/* current victim section num */
unsigned int gc_mode; /* current GC state */
unsigned int next_victim_seg[2];/* next segment in victim
section */
+
/* for skip statistic */
unsigned int atomic_files; /* # of opened atomic file */
unsigned long long skipped_atomic_files[2]; /* FG_GC and BG_GC */
@@ -2480,7 +2482,7 @@ static inline void *f2fs_kmem_cache_alloc(struct
kmem_cache *cachep,
static inline bool is_idle(struct f2fs_sb_info *sbi, int type)
{
- if (sbi->gc_mode == GC_URGENT)
+ if (sbi->gc_mode == GC_URGENT_HIGH)
return true;
if (get_pages(sbi, F2FS_RD_DATA) || get_pages(sbi, F2FS_RD_NODE) ||
@@ -2498,6 +2500,10 @@ static inline bool is_idle(struct f2fs_sb_info *sbi, int
type)
atomic_read(_I(sbi)->fcc_info->queued_flush))
return false;
+ if (sbi->gc_mode == GC_URGENT_LOW &&
+ (type == DISCARD_TIME || type == GC_TIME))
+ return true;
+
return f2fs_time_over(sbi, type);
}
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 6eec3b2d606d..3b718da69910 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -82,7 +82,7 @@ static int gc_thread_func(void *data)
* invalidated soon after by user update or deletion.
* So, I'd like to wait some time to collect dirty segments.
*/
- if (sbi->gc_mode == GC_URGENT) {
+ if (sbi->gc_mode == GC_URGENT_HIGH) {
wait_ms = gc_th->urgent_sleep_time;
down_write(>gc_lock);
goto do_gc;
@@ -176,7 +176,7 @@ static int select_gc_type(struct f2fs_sb_info *sbi, int
gc_type)
gc_mode = GC_CB;
break;
case GC_IDLE_GREEDY:
- case GC_URGENT:
+ case GC_URGENT_HIGH:
gc_mode = GC_GREEDY;
break;
}
@@ -211,7 +211,7 @@ static void select_policy(struct f2fs_sb_info *sbi, int
gc_type,
* foreground GC and urgent GC cases.
*/
if (gc_type != FG_GC &&
- (sbi->gc_mode != GC_URGENT) &&
+ (sbi->gc_mode != GC_URGENT_HIGH) &&
p->max_search > sbi->max_victim_search)
p->max_search = sbi->max_victim_search;
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index b45e473508a9..5924b3965ae4 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -174,7 +174,7 @@ bool f2fs_need_SSR(struct f2fs_sb_info *sbi)
if (f2fs_lfs_mode(sbi))
return false;
- if (sbi->gc_mode == GC_URGENT)
+ if (sbi->gc_mode == GC_URGENT_HIGH)
return true;
if (unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED)))
return true;
@@ -1759,7 +1759,7 @@ static int issue_discard_thread(void *data)
continue;
}
- if (sbi->gc_mode == GC_URGENT)
+ if (sbi->gc_mode == GC_URGENT_HIGH)
__init_discard_policy(sbi, , DPOLICY_FORCE, 1);
sb_start_intwrite(sbi->sb);
diff --git
Re: [PATCH v2 0/1] Revert "serial: 8250: Fix max baud limit in generic 8250 port"
On Thu, Jul 02, 2020 at 01:37:13AM +0300, Serge Semin wrote:
> 1) Add a new capability like UART_CAP_NO16DIV and take it into account
>in the serial8250_get_baud_rate() method.
>
> I don't have a documentation for the Mediatek UART port, but it seems to me
> that that controller calculates the baud rate differently from the standard
> 8250 port. A standard 8250 port does that by the next formulae:
> baud = uartclk / (16 * divisor).
> While it seems to me that the Mediatek port uses the formulae like:
> baud = uartclk / divisor. (Please, correct me if I'm wrong)
8250_bcm2835aux.c seems to suffer from a similar issue and
solves it like this in the ->probe hook:
/* the HW-clock divider for bcm2835aux is 8,
* but 8250 expects a divider of 16,
* so we have to multiply the actual clock by 2
* to get identical baudrates.
*/
up.port.uartclk = clk_get_rate(data->clk) * 2;
> 2) Manually call serial8250_do_set_divisor() in the custom set_termios()
>callback.
>
> Just add the uart_update_timeout() and serial8250_do_set_divisor() methods
> invocation into the mtk8250_set_termios() function, which the original commit
> 81bb549fdf14 ("serial: 8250_mtk: support big baud rate") author should have
> done in the first place.
That sound preferable as adding new quirks into core code feels
like a case of midlayer fallacy:
https://blog.ffwll.ch/2016/12/midlayers-once-more-with-feeling.html
Thanks,
Lukas
Re: [PATCH v4 12/37] PM / devfreq: tegra20: Use MC timings for building OPP table
Hi Dmitry,
On 6/9/20 10:13 PM, Dmitry Osipenko wrote:
> The clk_round_rate() won't be usable for building OPP table once
> interconnect support will be added to the EMC driver because that CLK API
> function limits the rounded rate based on the clk rate that is imposed by
> active clk-users, and thus, the rounding won't work as expected if
> interconnect will set the minimum EMC clock rate before devfreq driver is
> loaded. The struct tegra_mc contains memory timings which could be used by
> the devfreq driver for building up OPP table instead of rounding clock
> rate, this patch implements this idea.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra20-devfreq.c | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/devfreq/tegra20-devfreq.c
> b/drivers/devfreq/tegra20-devfreq.c
> index 6469dc69c5e0..bf504ca4dea2 100644
> --- a/drivers/devfreq/tegra20-devfreq.c
> +++ b/drivers/devfreq/tegra20-devfreq.c
> @@ -123,8 +123,7 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> {
> struct tegra_devfreq *tegra;
> struct tegra_mc *mc;
> - unsigned long max_rate;
> - unsigned long rate;
> + unsigned int i;
> int err;
>
> mc = tegra_get_memory_controller();
> @@ -151,12 +150,17 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
>
> tegra->regs = mc->regs;
>
> - max_rate = clk_round_rate(tegra->emc_clock, ULONG_MAX);
> -
> - for (rate = 0; rate <= max_rate; rate++) {
> - rate = clk_round_rate(tegra->emc_clock, rate);
> + if (!mc->num_timings) {
Could you explain what is meaning of 'num_timing?
Also, why add the opp entry in case of mc->num_timings is zero?
> + err = dev_pm_opp_add(>dev,
> + clk_get_rate(tegra->emc_clock), 0);
> + if (err) {
> + dev_err(>dev, "failed to add OPP: %d\n", err);
> + return err;
> + }
> + }
>
> - err = dev_pm_opp_add(>dev, rate, 0);
> + for (i = 0; i < mc->num_timings; i++) {
> + err = dev_pm_opp_add(>dev, mc->timings[i].rate, 0);
> if (err) {
> dev_err(>dev, "failed to add opp: %d\n", err);
> goto remove_opps;
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: linux-next: build warning after merge of the block tree
On 7/1/20 7:21 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> drivers/md/dm.c: In function '__map_bio':
> drivers/md/dm.c:1296:24: warning: unused variable 'md' [-Wunused-variable]
> 1296 | struct mapped_device *md = io->md;
> |^~
>
> Introduced by commit
>
> 5a6c35f9af41 ("block: remove direct_make_request")
Thanks, I did fix this one up, just haven't pushed out the updated tree
yet.
--
Jens Axboe
Re: [PATCH v33 11/21] x86/sgx: Linux Enclave Driver
On Thu, Jun 18, 2020 at 01:08:33AM +0300, Jarkko Sakkinen wrote:
> +static int sgx_validate_secs(const struct sgx_secs *secs,
> + unsigned long ssaframesize)
> +{
> + if (secs->size < (2 * PAGE_SIZE) || !is_power_of_2(secs->size))
> + return -EINVAL;
> +
> + if (secs->base & (secs->size - 1))
> + return -EINVAL;
> +
> + if (secs->miscselect & sgx_misc_reserved_mask ||
> + secs->attributes & sgx_attributes_reserved_mask ||
> + secs->xfrm & sgx_xfrm_reserved_mask)
> + return -EINVAL;
> +
> + if (secs->attributes & SGX_ATTR_MODE64BIT) {
> + if (secs->size > sgx_encl_size_max_64)
> + return -EINVAL;
> + } else if (secs->size > sgx_encl_size_max_32)
> + return -EINVAL;
These should be >=, not >, the SDM uses one of those fancy ≥ ligatures.
Internal versions use more obvious pseudocode, e.g.:
if ((DS:TMP_SECS.ATTRIBUTES.MODE64BIT = 1) AND
(DS:TMP_SECS.SIZE AND (~((1 << CPUID.18.0:EDX[15:8]) – 1)))
{
#GP(0);
}
> +
> + if (!(secs->xfrm & XFEATURE_MASK_FP) ||
> + !(secs->xfrm & XFEATURE_MASK_SSE) ||
> + (((secs->xfrm >> XFEATURE_BNDREGS) & 1) !=
> + ((secs->xfrm >> XFEATURE_BNDCSR) & 1)))
> + return -EINVAL;
> +
> + if (!secs->ssa_frame_size || ssaframesize > secs->ssa_frame_size)
> + return -EINVAL;
> +
> + if (memchr_inv(secs->reserved1, 0, sizeof(secs->reserved1)) ||
> + memchr_inv(secs->reserved2, 0, sizeof(secs->reserved2)) ||
> + memchr_inv(secs->reserved3, 0, sizeof(secs->reserved3)) ||
> + memchr_inv(secs->reserved4, 0, sizeof(secs->reserved4)))
> + return -EINVAL;
> +
> + return 0;
> +}
RE: [PATCH V4 5/5] clk: imx8qxp: Support building i.MX8QXP clock driver as module
> Subject: Re: [PATCH V4 5/5] clk: imx8qxp: Support building i.MX8QXP clock
> driver as module
>
> On Thu, Jul 2, 2020 at 10:20 AM Anson Huang
> wrote:
> >
> > Change configuration to "tristate", use device_initcall() instead of
> > builtin_platform_driver(), add module author, description and license
> > to support building i.MX8QXP clock drivers as module.
> >
> > Signed-off-by: Anson Huang
> > ---
> > Changes since V3:
> > - use device_initcall() instead of builtin_platform_driver();
> > - add module author/description;
> > - link common scu/lpcg clock driver to i.MX8QXP clock driver, then
> > no need to have exports.
> > ---
> > drivers/clk/imx/Kconfig| 6 +++---
> > drivers/clk/imx/Makefile | 9 -
> > drivers/clk/imx/clk-imx8qxp-lpcg.c | 10 +-
> > drivers/clk/imx/clk-imx8qxp.c | 11 ++-
> > 4 files changed, 26 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index
> > 1867111..8340dfe 100644
> > --- a/drivers/clk/imx/Kconfig
> > +++ b/drivers/clk/imx/Kconfig
> > @@ -5,8 +5,8 @@ config MXC_CLK
> > depends on ARCH_MXC
> >
> > config MXC_CLK_SCU
> > - bool
> > - depends on IMX_SCU
> > + tristate "IMX SCU clock"
> > + depends on ARCH_MXC && IMX_SCU
> >
> > config CLK_IMX1
> > bool "IMX1 CCM Clock Driver"
> > @@ -127,7 +127,7 @@ config CLK_IMX8MQ
> > Build the driver for i.MX8MQ CCM Clock Driver
> >
> > config CLK_IMX8QXP
> > - bool "IMX8QXP SCU Clock"
> > + tristate "IMX8QXP SCU Clock"
> > depends on ARCH_MXC && IMX_SCU && ARM64
> > select MXC_CLK_SCU
> > help
> > diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile index
> > 17f5d12..79e53f2 100644
> > --- a/drivers/clk/imx/Makefile
> > +++ b/drivers/clk/imx/Makefile
> > @@ -21,15 +21,14 @@ mxc-clk-objs += clk-pll14xx.o mxc-clk-objs +=
> > clk-sscg-pll.o
> > obj-$(CONFIG_MXC_CLK) += mxc-clk.o
> >
> > -obj-$(CONFIG_MXC_CLK_SCU) += \
> > - clk-scu.o \
> > - clk-lpcg-scu.o
> > -
> > obj-$(CONFIG_CLK_IMX8MM) += clk-imx8mm.o
> > obj-$(CONFIG_CLK_IMX8MN) += clk-imx8mn.o
> > obj-$(CONFIG_CLK_IMX8MP) += clk-imx8mp.o
> > obj-$(CONFIG_CLK_IMX8MQ) += clk-imx8mq.o
> > -obj-$(CONFIG_CLK_IMX8QXP) += clk-imx8qxp.o clk-imx8qxp-lpcg.o
> > +
> > +obj-$(CONFIG_MXC_CLK_SCU) += clk-imx-scu.o clk-imx-lpcg-scu.o
> > +clk-imx-scu-$(CONFIG_CLK_IMX8QXP) += clk-scu.o clk-imx8qxp.o
> > +clk-imx-lpcg-scu-$(CONFIG_CLK_IMX8QXP) += clk-lpcg-scu.o
> > +clk-imx8qxp-lpcg.o
> >
> > obj-$(CONFIG_CLK_IMX1) += clk-imx1.o
> > obj-$(CONFIG_CLK_IMX21) += clk-imx21.o diff --git
> > a/drivers/clk/imx/clk-imx8qxp-lpcg.c
> > b/drivers/clk/imx/clk-imx8qxp-lpcg.c
> > index 04c8ee3..5b6648e 100644
> > --- a/drivers/clk/imx/clk-imx8qxp-lpcg.c
> > +++ b/drivers/clk/imx/clk-imx8qxp-lpcg.c
> > @@ -231,4 +231,12 @@ static struct platform_driver
> imx8qxp_lpcg_clk_driver = {
> > .probe = imx8qxp_lpcg_clk_probe, };
> >
> > -builtin_platform_driver(imx8qxp_lpcg_clk_driver);
> > +static int __init imx8qxp_lpcg_clk_init(void)
>
> Does __init work for module?
__init is NOT working/necessary for module, but if the driver is built-in, it
is better to
have it, checked other drivers which support module build, they all have it, so
I think
it is better to keep it especially when the driver supports both built-in and
loadable module.
drivers/clk/qcom/gcc-sdm845.c
drivers/clk/qcom/gcc-msm8939.c
>
> > +{
> > + return platform_driver_register(_lpcg_clk_driver);
> > +}
> > +device_initcall(imx8qxp_lpcg_clk_init);
>
> Any reason to change to device_initcall which looks a bit strange?
> Is it because the following line?
> +obj-$(CONFIG_MXC_CLK_SCU) += clk-imx-scu.o clk-imx-lpcg-scu.o
> But it looks to me they're still two modules. Aren't they?
It is suggested by Arnd to NOT use builtin_platform_driver(), in order to
support module
unload, although the clock driver normally does NOT support remove, but it is
better to
follow the right way.
The change in Makefile is just to link scu/lpcg library to i.MX8QXP clk driver,
so that we can
get rid of exports and below 2 .ko are needed for all i.MX SoCs with SCU inside
as per your
saying of i.MX8QXP clock driver can be extended for future SoCs with SCU.
clk-imx-lpcg-scu.ko
clk-imx-scu.ko
Thanks,
Anson
[PATCH v1 0/2] atheros: use generic power management
Linux Kernel Mentee: Remove Legacy Power Management. The purpose of this patch series is to remove legacy power management callbacks from atheros ethernet drivers. The callbacks performing suspend() and resume() operations are still calling pci_save_state(), pci_set_power_state(), etc. and handling the power management themselves, which is not recommended. The conversion requires the removal of the those function calls and change the callback definition accordingly and make use of dev_pm_ops structure. All patches are compile-tested only. Vaibhav Gupta (2): atl1e: use generic power management atl2: use generic power management .../net/ethernet/atheros/atl1e/atl1e_main.c | 53 --- drivers/net/ethernet/atheros/atlx/atl2.c | 64 ++- 2 files changed, 31 insertions(+), 86 deletions(-) -- 2.27.0
[PATCH v1 2/2] atl2: use generic power management
Remove legacy PM callbacks and use generic operations. With legacy code,
drivers were responsible for handling PCI PM operations like
pci_save_state(). In generic code, all these hre andled by PCI core.
The generic suspend() and resume() are called at the same point the legacy
ones were called. Thus, it does not affect the normal functioning of the
driver.
__maybe_unused attribute is used with .resume() but not with .suspend(), as
.suspend() is calleb by .shutdown().
Compile-tested only.
Signed-off-by: Vaibhav Gupta
---
drivers/net/ethernet/atheros/atlx/atl2.c | 64 +++-
1 file changed, 18 insertions(+), 46 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atlx/atl2.c
b/drivers/net/ethernet/atheros/atlx/atl2.c
index c915852b8892..3e01e9fdb7fd 100644
--- a/drivers/net/ethernet/atheros/atlx/atl2.c
+++ b/drivers/net/ethernet/atheros/atlx/atl2.c
@@ -1484,19 +1484,15 @@ static void atl2_remove(struct pci_dev *pdev)
pci_disable_device(pdev);
}
-static int atl2_suspend(struct pci_dev *pdev, pm_message_t state)
+static int atl2_suspend(struct device *dev_d)
{
- struct net_device *netdev = pci_get_drvdata(pdev);
+ struct net_device *netdev = dev_get_drvdata(dev_d);
struct atl2_adapter *adapter = netdev_priv(netdev);
struct atl2_hw *hw = >hw;
u16 speed, duplex;
u32 ctrl = 0;
u32 wufc = adapter->wol;
-#ifdef CONFIG_PM
- int retval = 0;
-#endif
-
netif_device_detach(netdev);
if (netif_running(netdev)) {
@@ -1504,12 +1500,6 @@ static int atl2_suspend(struct pci_dev *pdev,
pm_message_t state)
atl2_down(adapter);
}
-#ifdef CONFIG_PM
- retval = pci_save_state(pdev);
- if (retval)
- return retval;
-#endif
-
atl2_read_phy_reg(hw, MII_BMSR, (u16 *));
atl2_read_phy_reg(hw, MII_BMSR, (u16 *));
if (ctrl & BMSR_LSTATUS)
@@ -1560,7 +1550,7 @@ static int atl2_suspend(struct pci_dev *pdev,
pm_message_t state)
ctrl |= PCIE_DLL_TX_CTRL1_SEL_NOR_CLK;
ATL2_WRITE_REG(hw, REG_PCIE_DLL_TX_CTRL1, ctrl);
- pci_enable_wake(pdev, pci_choose_state(pdev, state), 1);
+ device_wakeup_enable(dev_d);
goto suspend_exit;
}
@@ -1580,7 +1570,7 @@ static int atl2_suspend(struct pci_dev *pdev,
pm_message_t state)
hw->phy_configured = false; /* re-init PHY when resume */
- pci_enable_wake(pdev, pci_choose_state(pdev, state), 1);
+ device_wakeup_enable(dev_d);
goto suspend_exit;
}
@@ -1600,42 +1590,26 @@ static int atl2_suspend(struct pci_dev *pdev,
pm_message_t state)
atl2_force_ps(hw);
hw->phy_configured = false; /* re-init PHY when resume */
- pci_enable_wake(pdev, pci_choose_state(pdev, state), 0);
+ device_wakeup_disable(dev_d);
suspend_exit:
if (netif_running(netdev))
atl2_free_irq(adapter);
- pci_disable_device(pdev);
-
- pci_set_power_state(pdev, pci_choose_state(pdev, state));
-
return 0;
}
-#ifdef CONFIG_PM
-static int atl2_resume(struct pci_dev *pdev)
+static int __maybe_unused atl2_resume(struct device *dev_d)
{
- struct net_device *netdev = pci_get_drvdata(pdev);
+ struct net_device *netdev = dev_get_drvdata(dev_d);
struct atl2_adapter *adapter = netdev_priv(netdev);
u32 err;
- pci_set_power_state(pdev, PCI_D0);
- pci_restore_state(pdev);
-
- err = pci_enable_device(pdev);
- if (err) {
- printk(KERN_ERR
- "atl2: Cannot enable PCI device from suspend\n");
- return err;
- }
-
- pci_set_master(pdev);
+ pci_set_master(to_pci_dev(dev_d));
ATL2_READ_REG(>hw, REG_WOL_CTRL); /* clear WOL status */
- pci_enable_wake(pdev, PCI_D3hot, 0);
- pci_enable_wake(pdev, PCI_D3cold, 0);
+ device_wakeup_disable(dev_d);
ATL2_WRITE_REG(>hw, REG_WOL_CTRL, 0);
@@ -1654,24 +1628,22 @@ static int atl2_resume(struct pci_dev *pdev)
return 0;
}
-#endif
static void atl2_shutdown(struct pci_dev *pdev)
{
- atl2_suspend(pdev, PMSG_SUSPEND);
+ atl2_suspend(>dev);
}
+static SIMPLE_DEV_PM_OPS(atl2_pm_ops, atl2_suspend, atl2_resume);
+
static struct pci_driver atl2_driver = {
- .name = atl2_driver_name,
- .id_table = atl2_pci_tbl,
- .probe= atl2_probe,
- .remove = atl2_remove,
+ .name = atl2_driver_name,
+ .id_table = atl2_pci_tbl,
+ .probe = atl2_probe,
+ .remove= atl2_remove,
/* Power Management Hooks */
- .suspend = atl2_suspend,
-#ifdef CONFIG_PM
- .resume = atl2_resume,
-#endif
- .shutdown = atl2_shutdown,
+ .driver.pm = _pm_ops,
+ .shutdown = atl2_shutdown,
};
/**
--
2.27.0
[PATCH v1 1/2] atl1e: use generic power management
Remove legacy PM callbacks and use generic operations. With legacy code,
drivers were responsible for handling PCI PM operations like
pci_save_state(). In generic code, all these hre andled by PCI core.
The generic suspend() and resume() are called at the same point the legacy
ones were called. Thus, it does not affect the normal functioning of the
driver.
__maybe_unused attribute is used with .resume() but not with .suspend(), as
.suspend() is calleb by .shutdown().
Compile-tested only.
Signed-off-by: Vaibhav Gupta
---
.../net/ethernet/atheros/atl1e/atl1e_main.c | 53 +--
1 file changed, 13 insertions(+), 40 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
index 223ef846123e..9b03299ba665 100644
--- a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
+++ b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
@@ -2048,9 +2048,9 @@ static int atl1e_close(struct net_device *netdev)
return 0;
}
-static int atl1e_suspend(struct pci_dev *pdev, pm_message_t state)
+static int atl1e_suspend(struct device *dev_d)
{
- struct net_device *netdev = pci_get_drvdata(pdev);
+ struct net_device *netdev = dev_get_drvdata(dev_d);
struct atl1e_adapter *adapter = netdev_priv(netdev);
struct atl1e_hw *hw = >hw;
u32 ctrl = 0;
@@ -2061,9 +2061,6 @@ static int atl1e_suspend(struct pci_dev *pdev,
pm_message_t state)
u16 mii_intr_status_data = 0;
u32 wufc = adapter->wol;
u32 i;
-#ifdef CONFIG_PM
- int retval = 0;
-#endif
if (netif_running(netdev)) {
WARN_ON(test_bit(__AT_RESETTING, >flags));
@@ -2071,12 +2068,6 @@ static int atl1e_suspend(struct pci_dev *pdev,
pm_message_t state)
}
netif_device_detach(netdev);
-#ifdef CONFIG_PM
- retval = pci_save_state(pdev);
- if (retval)
- return retval;
-#endif
-
if (wufc) {
/* get link status */
atl1e_read_phy_reg(hw, MII_BMSR, _bmsr_data);
@@ -2146,7 +2137,7 @@ static int atl1e_suspend(struct pci_dev *pdev,
pm_message_t state)
ctrl = AT_READ_REG(hw, REG_PCIE_PHYMISC);
ctrl |= PCIE_PHYMISC_FORCE_RCV_DET;
AT_WRITE_REG(hw, REG_PCIE_PHYMISC, ctrl);
- pci_enable_wake(pdev, pci_choose_state(pdev, state), 1);
+ device_wakeup_enable(dev_d);
goto suspend_exit;
}
wol_dis:
@@ -2162,43 +2153,27 @@ static int atl1e_suspend(struct pci_dev *pdev,
pm_message_t state)
atl1e_force_ps(hw);
hw->phy_configured = false; /* re-init PHY when resume */
- pci_enable_wake(pdev, pci_choose_state(pdev, state), 0);
+ device_wakeup_disable(dev_d);
suspend_exit:
if (netif_running(netdev))
atl1e_free_irq(adapter);
- pci_disable_device(pdev);
-
- pci_set_power_state(pdev, pci_choose_state(pdev, state));
-
return 0;
}
-#ifdef CONFIG_PM
-static int atl1e_resume(struct pci_dev *pdev)
+static int __maybe_unused atl1e_resume(struct device *dev_d)
{
- struct net_device *netdev = pci_get_drvdata(pdev);
+ struct net_device *netdev = dev_get_drvdata(dev_d);
struct atl1e_adapter *adapter = netdev_priv(netdev);
u32 err;
- pci_set_power_state(pdev, PCI_D0);
- pci_restore_state(pdev);
-
- err = pci_enable_device(pdev);
- if (err) {
- netdev_err(adapter->netdev,
- "Cannot enable PCI device from suspend\n");
- return err;
- }
-
- pci_set_master(pdev);
+ pci_set_master(to_pci_dev(dev_d));
AT_READ_REG(>hw, REG_WOL_CTRL); /* clear WOL status */
- pci_enable_wake(pdev, PCI_D3hot, 0);
- pci_enable_wake(pdev, PCI_D3cold, 0);
+ device_wakeup_disable(dev_d);
AT_WRITE_REG(>hw, REG_WOL_CTRL, 0);
@@ -2217,11 +2192,10 @@ static int atl1e_resume(struct pci_dev *pdev)
return 0;
}
-#endif
static void atl1e_shutdown(struct pci_dev *pdev)
{
- atl1e_suspend(pdev, PMSG_SUSPEND);
+ atl1e_suspend(>dev);
}
static const struct net_device_ops atl1e_netdev_ops = {
@@ -2533,16 +2507,15 @@ static const struct pci_error_handlers
atl1e_err_handler = {
.resume = atl1e_io_resume,
};
+static SIMPLE_DEV_PM_OPS(atl1e_pm_ops, atl1e_suspend, atl1e_resume);
+
static struct pci_driver atl1e_driver = {
.name = atl1e_driver_name,
.id_table = atl1e_pci_tbl,
.probe= atl1e_probe,
.remove = atl1e_remove,
- /* Power Management Hooks */
-#ifdef CONFIG_PM
- .suspend = atl1e_suspend,
- .resume = atl1e_resume,
-#endif
+ /* Power Management Hook */
+ .driver.pm = _pm_ops,
.shutdown = atl1e_shutdown,
.err_handler = _err_handler
};
--
2.27.0
Re: [PATCH v4 15/23] ASoC: soc-core: Identify 'no_pcm' DAI links for DPCM
On 7/2/2020 6:22 AM, Kuninori Morimoto wrote: External email: Use caution opening links or attachments Hi Sameer At least my CPU driver doesn't use component:pcm_construct but is using DAI:pcm_new for some reasons. I'm not sure checking DAI:pcm here is enough, or not... OK. If adding DAI:pcm_new above here is not sufficient, then a flag can be used to describe FE component? or is there a better alternative? soc_component_is_pcm() is called from simple_dai_link_of_dpcm :: "FE" side. Yes I had to use this on "FE" side only because I wanted to find a real "FE" in FE<->BE and BE<->BE links. Please have a look at patch [23/23] for the sound DT binding I am using. Basically I want to connect multiple components in a chained fashion (FE <-> BE1 <-> BE2 ... ). Some of these BEs can be SoC components like resampler/mixer/mux/de-mux etc., the HW I am using has a cross bar which allows me to select/connect BEs in any order and I am trying to have the same flexibility here. Hence I only want to create PCM devices for real "FE" and trying to use simple-card as much as possible. More details about the HW and problems were discussed in [0]. [0] https://lkml.org/lkml/2020/4/30/519 I wonder component->driver->non_legacy_dai_naming can't work for you ? I see currently in simple-card driver that, BE<->BE link would be treated as CODEC<->CODEC link if 'non_legacy_dai_naming' flag is set at both ends of BE. Do we need to set this flag for all BE? However I am not sure how this will work out for a BE<->BE DPCM DAI link considering the fact that I want to use chain of components and I guess routing map would get complicated. Also going by the flag name it was not meant to differentiate between a FE and BE? Thank you for your help !! Best regards --- Kuninori Morimoto
RE: UART/TTY console deadlock
Hi All, Can we land this patch upstream? Feel free to add my tested-by. Thanks. Regards, Shirish S -Original Message- From: S, Shirish Sent: Wednesday, July 1, 2020 12:15 PM To: Tony Lindgren ; Sergey Senozhatsky Cc: Petr Mladek ; Andy Shevchenko ; Raul Rangel ; Sergey Senozhatsky ; linux-kernel ; Greg Kroah-Hartman ; Andy Shevchenko ; k...@linutronix.de; S, Shirish ; Peter Zijlstra ; John Ogness ; Steven Rostedt Subject: Re: UART/TTY console deadlock On 6/30/2020 11:32 PM, Tony Lindgren wrote: > * Sergey Senozhatsky [200630 13:06]: >> On (20/06/30 14:22), Petr Mladek wrote: > ... > >> @@ -2284,8 +2289,6 @@ int serial8250_do_startup(struct uart_port *port) >> * allow register changes to become visible. >> */ >> spin_lock_irqsave(>lock, flags); >> -if (up->port.irqflags & IRQF_SHARED) >> -disable_irq_nosync(port->irq); >> >> wait_for_xmitr(up, UART_LSR_THRE); >> serial_port_out_sync(port, UART_IER, UART_IER_THRI); @@ >> -2297,9 +2300,9 @@ int serial8250_do_startup(struct uart_port *port) >> iir = serial_port_in(port, UART_IIR); >> serial_port_out(port, UART_IER, 0); >> >> -if (port->irqflags & IRQF_SHARED) >> -enable_irq(port->irq); >> spin_unlock_irqrestore(>lock, flags); >> +if (irq_shared) >> +enable_irq(port->irq); >> >> /* >> * If the interrupt is not reasserted, or we otherwise > I think that it might be safe but I am not 100% sure, sigh. Yeah, I'm not 100%, but I'd give it a try. >>> I do not feel brave enough to ack it today. But I am all for trying >>> it if anyone more familiar with the code is fine with it. >> I see. Well, I suppose we need Ack-s from tty/serial/8250 maintainers. >> I would not be very happy if _only_ printk people Ack the patch. FWIW, the lockdep trace is not seen anymore with the patch applied. Regards, Shirish S > This conditional disable for irq_shared does not look nice to me from > the other device point of view :) > > Would it be possible to just set up te dummy interrupt handler for the > startup, then change it back afterwards? See for example > omap8250_no_handle_irq(). > > The other device for irq_shared should be capable of dealing with > spurious interrupts if it's shared. > > Regards, > > Tony -- Regards, Shirish S
Re: [RFC PATCH v1] scsi: ufs: Quiesce all scsi devices before shutdown
Hi Bart,
On Wed, 2020-07-01 at 20:02 -0700, Bart Van Assche wrote:
> On 2020-07-01 18:32, Stanley Chu wrote:
> > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> > index 59358bb75014..cadfa9006972 100644
> > --- a/drivers/scsi/ufs/ufshcd.c
> > +++ b/drivers/scsi/ufs/ufshcd.c
> > @@ -8599,10 +8599,14 @@ EXPORT_SYMBOL(ufshcd_runtime_idle);
> > int ufshcd_shutdown(struct ufs_hba *hba)
> > {
> > int ret = 0;
> > + struct scsi_target *starget;
> >
> > if (!hba->is_powered)
> > goto out;
> >
> > + list_for_each_entry(starget, >host->__targets, siblings)
> > + scsi_target_quiesce(starget);
> > +
> > if (ufshcd_is_ufs_dev_poweroff(hba) && ufshcd_is_link_off(hba))
> > goto out;
>
> Please add a comment above the list_for_each_entry() loop that explains
> that there is no matching scsi_target_unquiesce() call and also that
> SCSI commands queued after the scsi_target_quiesce() call returned will
> block until blk_cleanup_queue() is called (see also the blk_queue_dying()
> check in blk_queue_enter()).
Thanks for the review.
I'll add above comments in RFC v2.
Thanks,
Stanley Chu
[RFC PATCH v2] scsi: ufs: Quiesce all scsi devices before shutdown
Currently I/O request could be still submitted to UFS device while
UFS is working on shutdown flow. This may lead to racing as below
scenarios and finally system may crash due to unclocked register
accesses.
To fix this kind of issues, specifically quiesce all SCSI devices
before UFS shutdown to block all I/O request sending from block
layer.
Example of racing scenario: While UFS device is runtime-suspended
Thread #1: Executing UFS shutdown flow, e.g.,
ufshcd_suspend(UFS_SHUTDOWN_PM)
Thread #2: Executing runtime resume flow triggered by I/O request,
e.g., ufshcd_resume(UFS_RUNTIME_PM)
This breaks the assumption that UFS PM flows can not be running
concurrently and some unexpected racing behavior may happen.
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufshcd.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 59358bb75014..18da2d64f9fa 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8599,10 +8599,27 @@ EXPORT_SYMBOL(ufshcd_runtime_idle);
int ufshcd_shutdown(struct ufs_hba *hba)
{
int ret = 0;
+ struct scsi_target *starget;
if (!hba->is_powered)
goto out;
+ /*
+* Quiesce all SCSI devices to prevent any non-PM requests sending
+* from block layer during and after shutdown.
+*
+* Here we can not use blk_cleanup_queue() since PM requests
+* (with BLK_MQ_REQ_PREEMPT flag) are still required to be sent
+* through block layer. Therefore SCSI command queued after the
+* scsi_target_quiesce() call returned will block until
+* blk_cleanup_queue() is called.
+*
+* Besides, scsi_target_"un"quiesce (e.g., scsi_target_resume) can
+* be ignored since shutdown is one-way flow.
+*/
+ list_for_each_entry(starget, >host->__targets, siblings)
+ scsi_target_quiesce(starget);
+
if (ufshcd_is_ufs_dev_poweroff(hba) && ufshcd_is_link_off(hba))
goto out;
--
2.18.0
[v2 PATCH] crypto: af_alg - Fix regression on empty requests
On Tue, Jun 30, 2020 at 02:18:11PM +0530, Naresh Kamboju wrote:
>
> Since we are on this subject,
> LTP af_alg02 test case fails on stable 4.9 and stable 4.4
> This is not a regression because the test case has been failing from
> the beginning.
>
> Is this test case expected to fail on stable 4.9 and 4.4 ?
> or any chance to fix this on these older branches ?
>
> Test output:
> af_alg02.c:52: BROK: Timed out while reading from request socket.
>
> ref:
> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.228-191-g082e807235d7/testrun/2884917/suite/ltp-crypto-tests/test/af_alg02/history/
> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.228-191-g082e807235d7/testrun/2884606/suite/ltp-crypto-tests/test/af_alg02/log
Actually this test really is broken. Even though empty requests
are legal, they should never be done with no write(2) at all.
Because this fundamentally breaks the use of a blocking read(2)
to wait for more data.
Granted this has been broken since 2017 but I'm not going to
reintroduce this just because of a broken test case.
So please either remove af_alg02 or fix it by adding a control
message through sendmsg(2).
Thanks,
---8<---
Some user-space programs rely on crypto requests that have no
control metadata. This broke when a check was added to require
the presence of control metadata with the ctx->init flag.
This patch fixes the regression by setting ctx->init as long as
one sendmsg(2) has been made, with or without a control message.
Reported-by: Sachin Sant
Reported-by: Naresh Kamboju
Fixes: f3c802a1f300 ("crypto: algif_aead - Only wake up when...")
Signed-off-by: Herbert Xu
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 9fcb91ea10c41..5882ed46f1adb 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -851,6 +851,7 @@ int af_alg_sendmsg(struct socket *sock, struct msghdr *msg,
size_t size,
err = -EINVAL;
goto unlock;
}
+ ctx->init = true;
if (init) {
ctx->enc = enc;
@@ -858,7 +859,6 @@ int af_alg_sendmsg(struct socket *sock, struct msghdr *msg,
size_t size,
memcpy(ctx->iv, con.iv->iv, ivsize);
ctx->aead_assoclen = con.aead_assoclen;
- ctx->init = true;
}
while (size) {
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
RE: [EXT] Re: [PATCH 1/2] arm64: dts: ls1088a: add more thermal zone support
Hi Shawn,
Do you think it is ok if the cooling devices are shared between thermal zones?
BR,
Andy
> -Original Message-
> From: Amit Kucheria
> Sent: 2020年6月30日 14:47
> To: Andy Tang
> Cc: Shawn Guo ; Leo Li ; Rob
> Herring ; lakml ;
> open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> ; LKML
> Subject: Re: [EXT] Re: [PATCH 1/2] arm64: dts: ls1088a: add more thermal
> zone support
>
> Caution: EXT Email
>
> On Tue, Jun 30, 2020 at 12:07 PM Andy Tang wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Amit Kucheria
> > > Sent: 2020年6月30日 13:37
> > > To: Andy Tang
> > > Cc: Shawn Guo ; Leo Li ;
> > > Rob Herring ; lakml
> > > ;
> > > open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> > > ; LKML
> > > Subject: Re: [EXT] Re: [PATCH 1/2] arm64: dts: ls1088a: add more
> > > thermal zone support
> > >
> > > Caution: EXT Email
> > >
> > > On Tue, Jun 30, 2020 at 10:58 AM Andy Tang
> wrote:
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Amit Kucheria
> > > > > Sent: 2020年6月30日 13:12
> > > > > To: Andy Tang
> > > > > Cc: Shawn Guo ; Leo Li
> > > > > ; Rob Herring ; lakml
> > > > > ;
> > > > > open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> > > > > ; LKML
> > > > >
> > > > > Subject: [EXT] Re: [PATCH 1/2] arm64: dts: ls1088a: add more
> > > > > thermal zone support
> > > > >
> > > > > Caution: EXT Email
> > > > >
> > > > > On Tue, Jun 30, 2020 at 8:56 AM wrote:
> > > > > >
> > > > > > From: Yuantian Tang
> > > > > >
> > > > > > There are 2 thermal zones in ls1088a soc. Add the other
> > > > > > thermal zone node to enable it.
> > > > > > Also update the values in calibration table to make the
> > > > > > temperatures monitored more precise.
> > > > > >
> > > > > > Signed-off-by: Yuantian Tang
> > > > > > ---
> > > > > > .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 100
> > > > > > +++---
> > > > > > 1 file changed, 62 insertions(+), 38 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > > > > b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > > > > index 36a799554620..ccbbc23e6c85 100644
> > > > > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > > > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > > > > @@ -129,19 +129,19 @@
> > > > > > };
> > > > > >
> > > > > > thermal-zones {
> > > > > > - cpu_thermal: cpu-thermal {
> > > > > > + core-cluster {
> > > > > > polling-delay-passive = <1000>;
> > > > > > polling-delay = <5000>;
> > > > > > thermal-sensors = < 0>;
> > > > > >
> > > > > > trips {
> > > > > > - cpu_alert: cpu-alert {
> > > > > > + core_cluster_alert:
> > > > > core-cluster-alert
> > > > > > + {
> > > > > > temperature =
> > > <85000>;
> > > > > > hysteresis =
> <2000>;
> > > > > > type = "passive";
> > > > > > };
> > > > > >
> > > > > > - cpu_crit: cpu-crit {
> > > > > > + core_cluster_crit:
> > > > > > + core-cluster-crit {
> > > > > > temperature =
> > > <95000>;
> > > > > > hysteresis =
> <2000>;
> > > > > > type = "critical";
> @@
> > > > > -150,7
> > > > > > +150,7 @@
> > > > > >
> > > > > > cooling-maps {
> > > > > > map0 {
> > > > > > - trip =
> <_alert>;
> > > > > > + trip =
> > > > > <_cluster_alert>;
> > > > > > cooling-device =
> > > > > > <
> > > > > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > > > > > <
> > > > > > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, @@ -163,6 +163,26
> @@
> > > > > > };
> > > > > > };
> > > > > > };
> > > > > > +
> > > > > > + soc {
> > > > > > + polling-delay-passive = <1000>;
> > > > > > + polling-delay = <5000>;
> > > > > > + thermal-sensors = < 1>;
> > > > > > +
> > > > > > + trips {
> > > > > > + soc-alert {
> > > > > > + temperature =
> > > <85000>;
> > > > > > + hysteresis =
> <2000>;
> > > > > > + type = "passive";
> > > > > > + };
> > > > > > +
> > > >
Re: [PATCH V4 5/5] clk: imx8qxp: Support building i.MX8QXP clock driver as module
On Thu, Jul 2, 2020 at 10:20 AM Anson Huang wrote:
>
> Change configuration to "tristate", use device_initcall() instead
> of builtin_platform_driver(), add module author, description and
> license to support building i.MX8QXP clock drivers as module.
>
> Signed-off-by: Anson Huang
> ---
> Changes since V3:
> - use device_initcall() instead of builtin_platform_driver();
> - add module author/description;
> - link common scu/lpcg clock driver to i.MX8QXP clock driver, then
> no need to have exports.
> ---
> drivers/clk/imx/Kconfig| 6 +++---
> drivers/clk/imx/Makefile | 9 -
> drivers/clk/imx/clk-imx8qxp-lpcg.c | 10 +-
> drivers/clk/imx/clk-imx8qxp.c | 11 ++-
> 4 files changed, 26 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig
> index 1867111..8340dfe 100644
> --- a/drivers/clk/imx/Kconfig
> +++ b/drivers/clk/imx/Kconfig
> @@ -5,8 +5,8 @@ config MXC_CLK
> depends on ARCH_MXC
>
> config MXC_CLK_SCU
> - bool
> - depends on IMX_SCU
> + tristate "IMX SCU clock"
> + depends on ARCH_MXC && IMX_SCU
>
> config CLK_IMX1
> bool "IMX1 CCM Clock Driver"
> @@ -127,7 +127,7 @@ config CLK_IMX8MQ
> Build the driver for i.MX8MQ CCM Clock Driver
>
> config CLK_IMX8QXP
> - bool "IMX8QXP SCU Clock"
> + tristate "IMX8QXP SCU Clock"
> depends on ARCH_MXC && IMX_SCU && ARM64
> select MXC_CLK_SCU
> help
> diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile
> index 17f5d12..79e53f2 100644
> --- a/drivers/clk/imx/Makefile
> +++ b/drivers/clk/imx/Makefile
> @@ -21,15 +21,14 @@ mxc-clk-objs += clk-pll14xx.o
> mxc-clk-objs += clk-sscg-pll.o
> obj-$(CONFIG_MXC_CLK) += mxc-clk.o
>
> -obj-$(CONFIG_MXC_CLK_SCU) += \
> - clk-scu.o \
> - clk-lpcg-scu.o
> -
> obj-$(CONFIG_CLK_IMX8MM) += clk-imx8mm.o
> obj-$(CONFIG_CLK_IMX8MN) += clk-imx8mn.o
> obj-$(CONFIG_CLK_IMX8MP) += clk-imx8mp.o
> obj-$(CONFIG_CLK_IMX8MQ) += clk-imx8mq.o
> -obj-$(CONFIG_CLK_IMX8QXP) += clk-imx8qxp.o clk-imx8qxp-lpcg.o
> +
> +obj-$(CONFIG_MXC_CLK_SCU) += clk-imx-scu.o clk-imx-lpcg-scu.o
> +clk-imx-scu-$(CONFIG_CLK_IMX8QXP) += clk-scu.o clk-imx8qxp.o
> +clk-imx-lpcg-scu-$(CONFIG_CLK_IMX8QXP) += clk-lpcg-scu.o clk-imx8qxp-lpcg.o
>
> obj-$(CONFIG_CLK_IMX1) += clk-imx1.o
> obj-$(CONFIG_CLK_IMX21) += clk-imx21.o
> diff --git a/drivers/clk/imx/clk-imx8qxp-lpcg.c
> b/drivers/clk/imx/clk-imx8qxp-lpcg.c
> index 04c8ee3..5b6648e 100644
> --- a/drivers/clk/imx/clk-imx8qxp-lpcg.c
> +++ b/drivers/clk/imx/clk-imx8qxp-lpcg.c
> @@ -231,4 +231,12 @@ static struct platform_driver imx8qxp_lpcg_clk_driver = {
> .probe = imx8qxp_lpcg_clk_probe,
> };
>
> -builtin_platform_driver(imx8qxp_lpcg_clk_driver);
> +static int __init imx8qxp_lpcg_clk_init(void)
Does __init work for module?
> +{
> + return platform_driver_register(_lpcg_clk_driver);
> +}
> +device_initcall(imx8qxp_lpcg_clk_init);
Any reason to change to device_initcall which looks a bit strange?
Is it because the following line?
+obj-$(CONFIG_MXC_CLK_SCU) += clk-imx-scu.o clk-imx-lpcg-scu.o
But it looks to me they're still two modules. Aren't they?
Regards
Aisheng
> +
> +MODULE_AUTHOR("Aisheng Dong ");
> +MODULE_DESCRIPTION("NXP i.MX8QXP LPCG clock driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/clk/imx/clk-imx8qxp.c b/drivers/clk/imx/clk-imx8qxp.c
> index 5e2903e..9bcf0d1 100644
> --- a/drivers/clk/imx/clk-imx8qxp.c
> +++ b/drivers/clk/imx/clk-imx8qxp.c
> @@ -151,4 +151,13 @@ static struct platform_driver imx8qxp_clk_driver = {
> },
> .probe = imx8qxp_clk_probe,
> };
> -builtin_platform_driver(imx8qxp_clk_driver);
> +
> +static int __init imx8qxp_clk_init(void)
> +{
> + return platform_driver_register(_clk_driver);
> +}
> +device_initcall(imx8qxp_clk_init);
> +
> +MODULE_AUTHOR("Aisheng Dong ");
> +MODULE_DESCRIPTION("NXP i.MX8QXP clock driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.7.4
>
RE: [PATCH V4 3/5] clk: imx: Support building i.MX common clock driver as module
> Subject: Re: [PATCH V4 3/5] clk: imx: Support building i.MX common clock > driver as module > > On Thu, Jul 2, 2020 at 10:19 AM Anson Huang > wrote: > > > > There are more and more requirements of building SoC specific drivers > > as modules, add support for building i.MX common clock driver as > > module to meet the requirement. > > > > Signed-off-by: Anson Huang > > --- > > Changes since V3: > > - ONLY include __setup_param() build for built-in, module build no > need > > to have it. > > --- > > drivers/clk/imx/Kconfig| 8 ++-- > > drivers/clk/imx/Makefile | 40 > +++--- > > drivers/clk/imx/clk-composite-8m.c | 2 ++ > > drivers/clk/imx/clk-cpu.c | 2 ++ > > drivers/clk/imx/clk-frac-pll.c | 2 ++ > > drivers/clk/imx/clk-gate2.c| 2 ++ > > drivers/clk/imx/clk-pll14xx.c | 5 + > > drivers/clk/imx/clk-sscg-pll.c | 2 ++ > > drivers/clk/imx/clk.c | 22 +++-- > > 9 files changed, 57 insertions(+), 28 deletions(-) > > > > diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index > > 09fc8ad..f6ddf76 100644 > > --- a/drivers/clk/imx/Kconfig > > +++ b/drivers/clk/imx/Kconfig > > @@ -1,8 +1,8 @@ > > # SPDX-License-Identifier: GPL-2.0 > > # common clock support for NXP i.MX SoC family. > > config MXC_CLK > > - bool > > - def_bool ARCH_MXC > > + tristate "IMX clock" > > + depends on ARCH_MXC > > > > config MXC_CLK_SCU > > bool > > @@ -101,24 +101,28 @@ config CLK_VF610 config CLK_IMX8MM > > bool "IMX8MM CCM Clock Driver" > > depends on ARCH_MXC > > + select MXC_CLK > > help > > Build the driver for i.MX8MM CCM Clock Driver > > > > config CLK_IMX8MN > > bool "IMX8MN CCM Clock Driver" > > depends on ARCH_MXC > > + select MXC_CLK > > help > > Build the driver for i.MX8MN CCM Clock Driver > > > > config CLK_IMX8MP > > bool "IMX8MP CCM Clock Driver" > > depends on ARCH_MXC > > + select MXC_CLK > > help > > Build the driver for i.MX8MP CCM Clock Driver > > > > config CLK_IMX8MQ > > bool "IMX8MQ CCM Clock Driver" > > depends on ARCH_MXC > > + select MXC_CLK > > help > > Build the driver for i.MX8MQ CCM Clock Driver > > > > diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile index > > 394ade7..17f5d12 100644 > > --- a/drivers/clk/imx/Makefile > > +++ b/drivers/clk/imx/Makefile > > @@ -1,25 +1,25 @@ > > # SPDX-License-Identifier: GPL-2.0 > > > > -obj-$(CONFIG_MXC_CLK) += \ > > - clk.o \ > > - clk-busy.o \ > > - clk-composite-8m.o \ > > - clk-cpu.o \ > > - clk-composite-7ulp.o \ > > - clk-divider-gate.o \ > > - clk-fixup-div.o \ > > - clk-fixup-mux.o \ > > - clk-frac-pll.o \ > > - clk-gate-exclusive.o \ > > - clk-gate2.o \ > > - clk-pfd.o \ > > - clk-pfdv2.o \ > > - clk-pllv1.o \ > > - clk-pllv2.o \ > > - clk-pllv3.o \ > > - clk-pllv4.o \ > > - clk-sscg-pll.o \ > > - clk-pll14xx.o > > +mxc-clk-objs += clk.o > > +mxc-clk-objs += clk-busy.o > > +mxc-clk-objs += clk-composite-7ulp.o > > +mxc-clk-objs += clk-composite-8m.o > > +mxc-clk-objs += clk-cpu.o > > +mxc-clk-objs += clk-divider-gate.o > > +mxc-clk-objs += clk-fixup-div.o > > +mxc-clk-objs += clk-fixup-mux.o > > +mxc-clk-objs += clk-frac-pll.o > > +mxc-clk-objs += clk-gate2.o > > +mxc-clk-objs += clk-gate-exclusive.o > > +mxc-clk-objs += clk-pfd.o > > +mxc-clk-objs += clk-pfdv2.o > > +mxc-clk-objs += clk-pllv1.o > > +mxc-clk-objs += clk-pllv2.o > > +mxc-clk-objs += clk-pllv3.o > > +mxc-clk-objs += clk-pllv4.o > > +mxc-clk-objs += clk-pll14xx.o > > +mxc-clk-objs += clk-sscg-pll.o > > +obj-$(CONFIG_MXC_CLK) += mxc-clk.o > > > > obj-$(CONFIG_MXC_CLK_SCU) += \ > > clk-scu.o \ > > diff --git a/drivers/clk/imx/clk-composite-8m.c > > b/drivers/clk/imx/clk-composite-8m.c > > index d2b5af8..78fb7e5 100644 > > --- a/drivers/clk/imx/clk-composite-8m.c > > +++ b/drivers/clk/imx/clk-composite-8m.c > > @@ -5,6 +5,7 @@ > > > > #include > > #include > > +#include > > #include > > #include > > > > @@ -243,3 +244,4 @@ struct clk_hw > *imx8m_clk_hw_composite_flags(const char *name, > > kfree(mux); > > return ERR_CAST(hw); > > } > > +EXPORT_SYMBOL_GPL(imx8m_clk_hw_composite_flags); > > diff --git a/drivers/clk/imx/clk-cpu.c b/drivers/clk/imx/clk-cpu.c > > index cb182be..cb6ca4c 100644 > > --- a/drivers/clk/imx/clk-cpu.c > > +++ b/drivers/clk/imx/clk-cpu.c > > @@ -5,6 +5,7 @@ > > > > #include > > #include > > +#include > > #include > > #include "clk.h" > > > > @@ -104,3 +105,4 @@ struct clk_hw *imx_clk_hw_cpu(const char *name, > > const char *parent_name, > > > > return hw; > > } > > +EXPORT_SYMBOL_GPL(imx_clk_hw_cpu); > > diff --git
[PATCH 4/4] arm64: dts: mediatek: Update allowed regulator modes for elm boards
This sets the allowed regulator modes for elm (and derivative) boards.
According to the datasheet, the da9211 does not support SLEEP mode.
Signed-off-by: Anand K Mistry
---
arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
index a5a12b2599a4..d4c84a856e7b 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include "mt8173.dtsi"
/ {
@@ -294,7 +295,8 @@ da9211_vcpu_reg: BUCKA {
regulator-max-microamp = <440>;
regulator-ramp-delay = <1>;
regulator-always-on;
- regulator-allowed-modes = <0 1>;
+ regulator-allowed-modes = ;
};
da9211_vgpu_reg: BUCKB {
--
2.27.0.212.ge8ba1cc988-goog
[PATCH 3/4] regulator: da9211: Implement of_map_mode
Implementing of_map_mode is necessary to be able to specify operating
modes in the devicetree using 'regulator-allowed-modes', and to change
regulator modes.
Signed-off-by: Anand K Mistry
---
drivers/regulator/da9211-regulator.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/da9211-regulator.c
b/drivers/regulator/da9211-regulator.c
index 1f9b75b41346..297b3aa7c753 100644
--- a/drivers/regulator/da9211-regulator.c
+++ b/drivers/regulator/da9211-regulator.c
@@ -86,6 +86,20 @@ static const int da9215_current_limits[] = {
560, 580, 600, 620, 640, 660, 680, 700
};
+static unsigned int da9211_map_buck_mode(unsigned int mode)
+{
+ switch (mode) {
+ case DA9211_BUCK_MODE_SLEEP:
+ return REGULATOR_MODE_STANDBY;
+ case DA9211_BUCK_MODE_SYNC:
+ return REGULATOR_MODE_FAST;
+ case DA9211_BUCK_MODE_AUTO:
+ return REGULATOR_MODE_NORMAL;
+ default:
+ return REGULATOR_MODE_INVALID;
+ }
+}
+
static unsigned int da9211_buck_get_mode(struct regulator_dev *rdev)
{
int id = rdev_get_id(rdev);
@@ -233,6 +247,7 @@ static const struct regulator_ops da9211_buck_ops = {
.vsel_reg = DA9211_REG_VBUCKA_A + DA9211_ID_##_id * 2,\
.vsel_mask = DA9211_VBUCK_MASK,\
.owner = THIS_MODULE,\
+ .of_map_mode = da9211_map_buck_mode,\
}
static struct regulator_desc da9211_regulators[] = {
@@ -242,8 +257,14 @@ static struct regulator_desc da9211_regulators[] = {
#ifdef CONFIG_OF
static struct of_regulator_match da9211_matches[] = {
- [DA9211_ID_BUCKA] = { .name = "BUCKA" },
- [DA9211_ID_BUCKB] = { .name = "BUCKB" },
+ [DA9211_ID_BUCKA] = {
+ .name = "BUCKA",
+ .desc = _regulators[DA9211_ID_BUCKA],
+ },
+ [DA9211_ID_BUCKB] = {
+ .name = "BUCKB",
+ .desc = _regulators[DA9211_ID_BUCKB],
+ },
};
static struct da9211_pdata *da9211_parse_regulators_dt(
--
2.27.0.212.ge8ba1cc988-goog
[PATCH 1/4] regulator: da9211: Move buck modes into header file
This will allow device trees to make use of these constants. Signed-off-by: Anand K Mistry --- drivers/regulator/da9211-regulator.c | 5 + .../dt-bindings/regulator/dlg,da9211-regulator.h | 16 2 files changed, 17 insertions(+), 4 deletions(-) create mode 100644 include/dt-bindings/regulator/dlg,da9211-regulator.h diff --git a/drivers/regulator/da9211-regulator.c b/drivers/regulator/da9211-regulator.c index 2ea4362ffa5c..1f9b75b41346 100644 --- a/drivers/regulator/da9211-regulator.c +++ b/drivers/regulator/da9211-regulator.c @@ -17,6 +17,7 @@ #include #include #include +#include #include "da9211-regulator.h" /* DEVICE IDs */ @@ -24,10 +25,6 @@ #define DA9213_DEVICE_ID 0x23 #define DA9215_DEVICE_ID 0x24 -#define DA9211_BUCK_MODE_SLEEP 1 -#define DA9211_BUCK_MODE_SYNC 2 -#define DA9211_BUCK_MODE_AUTO 3 - /* DA9211 REGULATOR IDs */ #define DA9211_ID_BUCKA0 #define DA9211_ID_BUCKB1 diff --git a/include/dt-bindings/regulator/dlg,da9211-regulator.h b/include/dt-bindings/regulator/dlg,da9211-regulator.h new file mode 100644 index ..cdce2d54c8ba --- /dev/null +++ b/include/dt-bindings/regulator/dlg,da9211-regulator.h @@ -0,0 +1,16 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _DT_BINDINGS_REGULATOR_DLG_DA9211_H +#define _DT_BINDINGS_REGULATOR_DLG_DA9211_H + +/* + * These buck mode constants may be used to specify values in device tree + * properties (e.g. regulator-initial-mode, regulator-allowed-modes). + * A description of the following modes is in the manufacturers datasheet. + */ + +#define DA9211_BUCK_MODE_SLEEP 1 +#define DA9211_BUCK_MODE_SYNC 2 +#define DA9211_BUCK_MODE_AUTO 3 + +#endif -- 2.27.0.212.ge8ba1cc988-goog
[PATCH 0/4] regulator: da9211: support changing modes
This patchset adds support for being able to change regulator modes for the da9211 regulator. This is needed to allow the voltage scaling support in the MT8173 SoC to be used in the elm (Acer Chromebook R13) and hana (several Lenovo Chromebooks) devices. Anand K Mistry (4): regulator: da9211: Move buck modes into header file dt-bindings: regulator: da9211: Document allowed modes regulator: da9211: Implement of_map_mode arm64: dts: mediatek: Update allowed regulator modes for elm boards .../devicetree/bindings/regulator/da9211.txt | 4 +++ arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 4 ++- drivers/regulator/da9211-regulator.c | 30 +++ .../regulator/dlg,da9211-regulator.h | 16 ++ 4 files changed, 47 insertions(+), 7 deletions(-) create mode 100644 include/dt-bindings/regulator/dlg,da9211-regulator.h -- 2.27.0.212.ge8ba1cc988-goog
[PATCH 2/4] dt-bindings: regulator: da9211: Document allowed modes
This patch adds a description of how operating modes may be specified.
Signed-off-by: Anand K Mistry
---
Documentation/devicetree/bindings/regulator/da9211.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/da9211.txt
b/Documentation/devicetree/bindings/regulator/da9211.txt
index 27717e816e71..eb871447d508 100644
--- a/Documentation/devicetree/bindings/regulator/da9211.txt
+++ b/Documentation/devicetree/bindings/regulator/da9211.txt
@@ -15,6 +15,8 @@ Required properties:
Optional properties:
- enable-gpios: platform gpio for control of BUCKA/BUCKB.
- Any optional property defined in regulator.txt
+ - regulator-initial-mode and regulator-allowed-modes may be specified using
+mode values from dt-bindings/regulator/dlg,da9211-regulator.h
Example 1) DA9211
pmic: da9211@68 {
@@ -30,6 +32,8 @@ Example 1) DA9211
regulator-min-microamp = <200>;
regulator-max-microamp = <500>;
enable-gpios = < 27 0>;
+ regulator-allowed-modes = ;
};
};
};
--
2.27.0.212.ge8ba1cc988-goog
arch/powerpc/boot/decompress.c:137: undefined reference to `__decompress'
Hi Christophe,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: cd77006e01b3198c75fb7819b3d0ff89709539bb
commit: 264bffad4d08f967ab3d6690bb15757a526b186a powerpc/boot: Add lzo support
for uImage
date: 12 months ago
config: powerpc-randconfig-r014-20200701 (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 264bffad4d08f967ab3d6690bb15757a526b186a
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
powerpc-linux-ld: arch/powerpc/boot/wrapper.a(decompress.o): in function
`partial_decompress':
>> arch/powerpc/boot/decompress.c:137: undefined reference to `__decompress'
vim +137 arch/powerpc/boot/decompress.c
1b7898ee276b39 Oliver O'Halloran 2016-09-22 102
1b7898ee276b39 Oliver O'Halloran 2016-09-22 103 /**
1b7898ee276b39 Oliver O'Halloran 2016-09-22 104 * partial_decompress -
decompresses part or all of a compressed buffer
1b7898ee276b39 Oliver O'Halloran 2016-09-22 105 * @inbuf: input buffer
1b7898ee276b39 Oliver O'Halloran 2016-09-22 106 * @input_size: length of
the input buffer
1b7898ee276b39 Oliver O'Halloran 2016-09-22 107 * @outbuf: input buffer
1b7898ee276b39 Oliver O'Halloran 2016-09-22 108 * @output_size: length of
the input buffer
1b7898ee276b39 Oliver O'Halloran 2016-09-22 109 * @skip number of
output bytes to ignore
1b7898ee276b39 Oliver O'Halloran 2016-09-22 110 *
1b7898ee276b39 Oliver O'Halloran 2016-09-22 111 * This function takes
compressed data from inbuf, decompresses and write it to
1b7898ee276b39 Oliver O'Halloran 2016-09-22 112 * outbuf. Once output_size
bytes are written to the output buffer, or the
1b7898ee276b39 Oliver O'Halloran 2016-09-22 113 * stream is exhausted the
function will return the number of bytes that were
1b7898ee276b39 Oliver O'Halloran 2016-09-22 114 * decompressed. Otherwise it
will return whatever error code the decompressor
1b7898ee276b39 Oliver O'Halloran 2016-09-22 115 * reported (NB: This is
specific to each decompressor type).
1b7898ee276b39 Oliver O'Halloran 2016-09-22 116 *
1b7898ee276b39 Oliver O'Halloran 2016-09-22 117 * The skip functionality is
mainly there so the program and discover
1b7898ee276b39 Oliver O'Halloran 2016-09-22 118 * the size of the compressed
image so that it can ask firmware (if present)
1b7898ee276b39 Oliver O'Halloran 2016-09-22 119 * for an appropriately sized
buffer.
1b7898ee276b39 Oliver O'Halloran 2016-09-22 120 */
1b7898ee276b39 Oliver O'Halloran 2016-09-22 121 long partial_decompress(void
*inbuf, unsigned long input_size,
1b7898ee276b39 Oliver O'Halloran 2016-09-22 122void *outbuf, unsigned
long output_size, unsigned long _skip)
1b7898ee276b39 Oliver O'Halloran 2016-09-22 123 {
1b7898ee276b39 Oliver O'Halloran 2016-09-22 124int ret;
1b7898ee276b39 Oliver O'Halloran 2016-09-22 125
1b7898ee276b39 Oliver O'Halloran 2016-09-22 126/*
1b7898ee276b39 Oliver O'Halloran 2016-09-22 127 * The skipped bytes
needs to be included in the size of data we want
1b7898ee276b39 Oliver O'Halloran 2016-09-22 128 * to decompress.
1b7898ee276b39 Oliver O'Halloran 2016-09-22 129 */
1b7898ee276b39 Oliver O'Halloran 2016-09-22 130output_size += _skip;
1b7898ee276b39 Oliver O'Halloran 2016-09-22 131
1b7898ee276b39 Oliver O'Halloran 2016-09-22 132decompressed_bytes = 0;
1b7898ee276b39 Oliver O'Halloran 2016-09-22 133output_buffer = outbuf;
1b7898ee276b39 Oliver O'Halloran 2016-09-22 134limit = output_size;
1b7898ee276b39 Oliver O'Halloran 2016-09-22 135skip = _skip;
1b7898ee276b39 Oliver O'Halloran 2016-09-22 136
1b7898ee276b39 Oliver O'Halloran 2016-09-22 @137ret =
__decompress(inbuf, input_size, NULL, flush, outbuf,
:: The code at line 137 was first introduced by commit
:: 1b7898ee276b39e54d870dc4ef3374f663d0b426 powerpc/boot: Use the pre-boot
decompression API
:: TO: Oliver O'Halloran
:: CC: Michael Ellerman
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: objtool clac/stac handling change..
> On Jul 1, 2020, at 7:30 PM, Linus Torvalds > wrote: > > On Wed, Jul 1, 2020 at 5:48 PM Andy Lutomirski wrote: >> >> You inspired me to mock it up. > > Ahh, you want to just use the jump folding of gcc to avoid the problem. > > I guess we could do that. Are there cases where this actually helps? > I was thinking it would help avoid brain melt. For better or for worse, the kernel is written in C, and readers don’t really expect call_some_function(arg, other arg) to actually teleport elsewhere in the function. I’m all for goto err; but at least that’s spelled “goto” and it’s really obvious what it does.
Re: [PATCH 2/2] virtio-mmio: Reject invalid IRQ 0 command line argument
On 2020/7/2 上午6:10, Bjorn Helgaas wrote:
From: Bjorn Helgaas
The "virtio_mmio.device=" command line argument allows a user to specify
the size, address, and IRQ of a virtio device. Previously the only
requirement for the IRQ was that it be an unsigned integer.
Zero is an unsigned integer but an invalid IRQ number, and after
a85a6c86c25be ("driver core: platform: Clarify that IRQ 0 is invalid"),
attempts to use IRQ 0 cause warnings.
If the user specifies IRQ 0, return failure instead of registering a device
with IRQ 0.
Fixes: a85a6c86c25be ("driver core: platform: Clarify that IRQ 0 is invalid")
Signed-off-by: Bjorn Helgaas
Cc: Michael S. Tsirkin
Cc: Jason Wang
Cc: virtualizat...@lists.linux-foundation.org
---
drivers/virtio/virtio_mmio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index 9d16aaffca9d..627ac0487494 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -641,11 +641,11 @@ static int vm_cmdline_set(const char *device,
_cmdline_id, );
/*
-* sscanf() must processes at least 2 chunks; also there
+* sscanf() must process at least 2 chunks; also there
* must be no extra characters after the last chunk, so
* str[consumed] must be '\0'
*/
- if (processed < 2 || str[consumed])
+ if (processed < 2 || str[consumed] || irq == 0)
return -EINVAL;
resources[0].flags = IORESOURCE_MEM;
Acked-by: Jason Wang
Re: [PATCH 4/8] cpufreq,vexpress-spc: fix Frequency Invariance (FI) for bL switching
On 01-07-20, 15:07, Ionela Voinescu wrote: > On Wednesday 01 Jul 2020 at 16:16:19 (+0530), Viresh Kumar wrote: > > Is there anyone who cares for this driver and EAS ? I will just skip doing > > the > > FIE thing here and mark it skipped. > > That is a good question. The vexpress driver is still used for TC2, but > I don't know of any users of this bL switcher functionality that's part > of the driver. I think there were a few people wondering recently if > it's still used [1]. Even if it is used by some, there is no need, I believe, to enable freq-invariance for it, which wasn't enabled until now. And considering that we are going to enable the flag only for the interested parties now, as from the discussion on 1/8, this shouldn't be required. -- viresh
Re: [PATCH V4 4/5] clk: imx8m: Support module build
On Thu, Jul 2, 2020 at 10:18 AM Anson Huang wrote:
>
> Change configuration to "tristate", add module author, description
> and license to support building i.MX8M SoCs clock driver as module.
>
> Signed-off-by: Anson Huang
Reviewed-by: Dong Aisheng
Regards
Aisheng
> ---
> Changes since V3:
> - add module author/description, and merge all i.MX8M SoCs patch into
> one patch.
> ---
> drivers/clk/imx/Kconfig | 8
> drivers/clk/imx/clk-imx8mm.c | 4
> drivers/clk/imx/clk-imx8mn.c | 4
> drivers/clk/imx/clk-imx8mp.c | 4
> drivers/clk/imx/clk-imx8mq.c | 4
> 5 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig
> index f6ddf76..1867111 100644
> --- a/drivers/clk/imx/Kconfig
> +++ b/drivers/clk/imx/Kconfig
> @@ -99,28 +99,28 @@ config CLK_VF610
> select MXC_CLK
>
> config CLK_IMX8MM
> - bool "IMX8MM CCM Clock Driver"
> + tristate "IMX8MM CCM Clock Driver"
> depends on ARCH_MXC
> select MXC_CLK
> help
> Build the driver for i.MX8MM CCM Clock Driver
>
> config CLK_IMX8MN
> - bool "IMX8MN CCM Clock Driver"
> + tristate "IMX8MN CCM Clock Driver"
> depends on ARCH_MXC
> select MXC_CLK
> help
> Build the driver for i.MX8MN CCM Clock Driver
>
> config CLK_IMX8MP
> - bool "IMX8MP CCM Clock Driver"
> + tristate "IMX8MP CCM Clock Driver"
> depends on ARCH_MXC
> select MXC_CLK
> help
> Build the driver for i.MX8MP CCM Clock Driver
>
> config CLK_IMX8MQ
> - bool "IMX8MQ CCM Clock Driver"
> + tristate "IMX8MQ CCM Clock Driver"
> depends on ARCH_MXC
> select MXC_CLK
> help
> diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
> index b793264..0de0be0 100644
> --- a/drivers/clk/imx/clk-imx8mm.c
> +++ b/drivers/clk/imx/clk-imx8mm.c
> @@ -657,3 +657,7 @@ static struct platform_driver imx8mm_clk_driver = {
> },
> };
> module_platform_driver(imx8mm_clk_driver);
> +
> +MODULE_AUTHOR("Bai Ping ");
> +MODULE_DESCRIPTION("NXP i.MX8MM clock driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
> index 213cc37..e984de5 100644
> --- a/drivers/clk/imx/clk-imx8mn.c
> +++ b/drivers/clk/imx/clk-imx8mn.c
> @@ -608,3 +608,7 @@ static struct platform_driver imx8mn_clk_driver = {
> },
> };
> module_platform_driver(imx8mn_clk_driver);
> +
> +MODULE_AUTHOR("Anson Huang ");
> +MODULE_DESCRIPTION("NXP i.MX8MN clock driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
> index ca74771..f3cedf2 100644
> --- a/drivers/clk/imx/clk-imx8mp.c
> +++ b/drivers/clk/imx/clk-imx8mp.c
> @@ -773,3 +773,7 @@ static struct platform_driver imx8mp_clk_driver = {
> },
> };
> module_platform_driver(imx8mp_clk_driver);
> +
> +MODULE_AUTHOR("Anson Huang ");
> +MODULE_DESCRIPTION("NXP i.MX8MP clock driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
> index a64aace..a06cc21 100644
> --- a/drivers/clk/imx/clk-imx8mq.c
> +++ b/drivers/clk/imx/clk-imx8mq.c
> @@ -643,3 +643,7 @@ static struct platform_driver imx8mq_clk_driver = {
> },
> };
> module_platform_driver(imx8mq_clk_driver);
> +
> +MODULE_AUTHOR("Abel Vesa ");
> +MODULE_DESCRIPTION("NXP i.MX8MQ clock driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.7.4
>
Re: [PATCH V4 3/5] clk: imx: Support building i.MX common clock driver as module
On Thu, Jul 2, 2020 at 10:19 AM Anson Huang wrote: > > There are more and more requirements of building SoC specific drivers > as modules, add support for building i.MX common clock driver as module > to meet the requirement. > > Signed-off-by: Anson Huang > --- > Changes since V3: > - ONLY include __setup_param() build for built-in, module build no > need > to have it. > --- > drivers/clk/imx/Kconfig| 8 ++-- > drivers/clk/imx/Makefile | 40 > +++--- > drivers/clk/imx/clk-composite-8m.c | 2 ++ > drivers/clk/imx/clk-cpu.c | 2 ++ > drivers/clk/imx/clk-frac-pll.c | 2 ++ > drivers/clk/imx/clk-gate2.c| 2 ++ > drivers/clk/imx/clk-pll14xx.c | 5 + > drivers/clk/imx/clk-sscg-pll.c | 2 ++ > drivers/clk/imx/clk.c | 22 +++-- > 9 files changed, 57 insertions(+), 28 deletions(-) > > diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig > index 09fc8ad..f6ddf76 100644 > --- a/drivers/clk/imx/Kconfig > +++ b/drivers/clk/imx/Kconfig > @@ -1,8 +1,8 @@ > # SPDX-License-Identifier: GPL-2.0 > # common clock support for NXP i.MX SoC family. > config MXC_CLK > - bool > - def_bool ARCH_MXC > + tristate "IMX clock" > + depends on ARCH_MXC > > config MXC_CLK_SCU > bool > @@ -101,24 +101,28 @@ config CLK_VF610 > config CLK_IMX8MM > bool "IMX8MM CCM Clock Driver" > depends on ARCH_MXC > + select MXC_CLK > help > Build the driver for i.MX8MM CCM Clock Driver > > config CLK_IMX8MN > bool "IMX8MN CCM Clock Driver" > depends on ARCH_MXC > + select MXC_CLK > help > Build the driver for i.MX8MN CCM Clock Driver > > config CLK_IMX8MP > bool "IMX8MP CCM Clock Driver" > depends on ARCH_MXC > + select MXC_CLK > help > Build the driver for i.MX8MP CCM Clock Driver > > config CLK_IMX8MQ > bool "IMX8MQ CCM Clock Driver" > depends on ARCH_MXC > + select MXC_CLK > help > Build the driver for i.MX8MQ CCM Clock Driver > > diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile > index 394ade7..17f5d12 100644 > --- a/drivers/clk/imx/Makefile > +++ b/drivers/clk/imx/Makefile > @@ -1,25 +1,25 @@ > # SPDX-License-Identifier: GPL-2.0 > > -obj-$(CONFIG_MXC_CLK) += \ > - clk.o \ > - clk-busy.o \ > - clk-composite-8m.o \ > - clk-cpu.o \ > - clk-composite-7ulp.o \ > - clk-divider-gate.o \ > - clk-fixup-div.o \ > - clk-fixup-mux.o \ > - clk-frac-pll.o \ > - clk-gate-exclusive.o \ > - clk-gate2.o \ > - clk-pfd.o \ > - clk-pfdv2.o \ > - clk-pllv1.o \ > - clk-pllv2.o \ > - clk-pllv3.o \ > - clk-pllv4.o \ > - clk-sscg-pll.o \ > - clk-pll14xx.o > +mxc-clk-objs += clk.o > +mxc-clk-objs += clk-busy.o > +mxc-clk-objs += clk-composite-7ulp.o > +mxc-clk-objs += clk-composite-8m.o > +mxc-clk-objs += clk-cpu.o > +mxc-clk-objs += clk-divider-gate.o > +mxc-clk-objs += clk-fixup-div.o > +mxc-clk-objs += clk-fixup-mux.o > +mxc-clk-objs += clk-frac-pll.o > +mxc-clk-objs += clk-gate2.o > +mxc-clk-objs += clk-gate-exclusive.o > +mxc-clk-objs += clk-pfd.o > +mxc-clk-objs += clk-pfdv2.o > +mxc-clk-objs += clk-pllv1.o > +mxc-clk-objs += clk-pllv2.o > +mxc-clk-objs += clk-pllv3.o > +mxc-clk-objs += clk-pllv4.o > +mxc-clk-objs += clk-pll14xx.o > +mxc-clk-objs += clk-sscg-pll.o > +obj-$(CONFIG_MXC_CLK) += mxc-clk.o > > obj-$(CONFIG_MXC_CLK_SCU) += \ > clk-scu.o \ > diff --git a/drivers/clk/imx/clk-composite-8m.c > b/drivers/clk/imx/clk-composite-8m.c > index d2b5af8..78fb7e5 100644 > --- a/drivers/clk/imx/clk-composite-8m.c > +++ b/drivers/clk/imx/clk-composite-8m.c > @@ -5,6 +5,7 @@ > > #include > #include > +#include > #include > #include > > @@ -243,3 +244,4 @@ struct clk_hw *imx8m_clk_hw_composite_flags(const char > *name, > kfree(mux); > return ERR_CAST(hw); > } > +EXPORT_SYMBOL_GPL(imx8m_clk_hw_composite_flags); > diff --git a/drivers/clk/imx/clk-cpu.c b/drivers/clk/imx/clk-cpu.c > index cb182be..cb6ca4c 100644 > --- a/drivers/clk/imx/clk-cpu.c > +++ b/drivers/clk/imx/clk-cpu.c > @@ -5,6 +5,7 @@ > > #include > #include > +#include > #include > #include "clk.h" > > @@ -104,3 +105,4 @@ struct clk_hw *imx_clk_hw_cpu(const char *name, const > char *parent_name, > > return hw; > } > +EXPORT_SYMBOL_GPL(imx_clk_hw_cpu); > diff --git a/drivers/clk/imx/clk-frac-pll.c b/drivers/clk/imx/clk-frac-pll.c > index 101e0a3..c703056 100644 > --- a/drivers/clk/imx/clk-frac-pll.c > +++ b/drivers/clk/imx/clk-frac-pll.c > @@ -10,6 +10,7 @@ > > #include > #include > +#include > #include > #include > #include > @@ -233,3 +234,4 @@ struct clk_hw *imx_clk_hw_frac_pll(const char *name, > > return hw; > } >
Re: [RFC PATCH v1] scsi: ufs: Quiesce all scsi devices before shutdown
On 2020-07-01 18:32, Stanley Chu wrote:
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 59358bb75014..cadfa9006972 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -8599,10 +8599,14 @@ EXPORT_SYMBOL(ufshcd_runtime_idle);
> int ufshcd_shutdown(struct ufs_hba *hba)
> {
> int ret = 0;
> + struct scsi_target *starget;
>
> if (!hba->is_powered)
> goto out;
>
> + list_for_each_entry(starget, >host->__targets, siblings)
> + scsi_target_quiesce(starget);
> +
> if (ufshcd_is_ufs_dev_poweroff(hba) && ufshcd_is_link_off(hba))
> goto out;
Please add a comment above the list_for_each_entry() loop that explains
that there is no matching scsi_target_unquiesce() call and also that
SCSI commands queued after the scsi_target_quiesce() call returned will
block until blk_cleanup_queue() is called (see also the blk_queue_dying()
check in blk_queue_enter()).
Thanks,
Bart.
Re: [PATCH 2/8] cpufreq: move invariance setter calls in cpufreq core
On 01-07-20, 17:51, Rafael J. Wysocki wrote: > On Wed, Jul 1, 2020 at 5:28 PM Ionela Voinescu > wrote: > > On Wednesday 01 Jul 2020 at 16:16:19 (+0530), Viresh Kumar wrote: > > > On 01-07-20, 10:07, Ionela Voinescu wrote: > > > > setpolicy() > > > > === > > > > This callback does not have any designated way of informing what was the > > > > end choice. But there are only two drivers using setpolicy(), and none > > > > of them have current FIE support: > > > > > > > > drivers/cpufreq/longrun.c:281:.setpolicy = > > > > longrun_set_policy, > > > > drivers/cpufreq/intel_pstate.c:2215: .setpolicy = > > > > intel_pstate_set_policy, > > > > > > > > The intel_pstate is known to use counter-driven frequency invariance. > > > > > > Same for acpi-cpufreq driver as well ? > > > > > > > The acpi-cpufreq driver defines target_index() and fast_switch() so it > > should go through the setting in cpufreq core. But x86 does not actually > > define arch_set_freq_scale() so when called it won't do anything (won't > > set any frequency scale factor), but rely on counters to set it through > > the arch_scale_freq_tick(). > > Right. > > So on x86 (Intel flavor of it at least), cpufreq has nothing to do > with this regardless of what driver is in use. -- viresh
ERROR: modpost: "bcsr_mod" undefined!
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: cd77006e01b3198c75fb7819b3d0ff89709539bb commit: 8d58f222e85f01da0c0e1fc1e77986c86de889e2 ubsan: disable UBSAN_ALIGNMENT under COMPILE_TEST date: 8 weeks ago config: mips-randconfig-r023-20200701 (attached as .config) compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project c8f1d442d0858f66fd4128fde6f67eb5202fa2b1) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install mips cross compiling tool for clang build # apt-get install binutils-mips-linux-gnu git checkout 8d58f222e85f01da0c0e1fc1e77986c86de889e2 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>, old ones prefixed by <<): >> ERROR: modpost: "bcsr_mod" [drivers/pcmcia/db1xxx_ss.ko] undefined! >> ERROR: modpost: "bcsr_read" [drivers/pcmcia/db1xxx_ss.ko] undefined! --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH v9 5/5] kdump: update Documentation about crashkernel on arm64
Hi Chen, On 06/28/20 at 04:34pm, Chen Zhou wrote: > Now we support crashkernel=X,[low] on arm64, update the Documentation. > We could use parameters "crashkernel=X crashkernel=Y,low" to reserve > memory above 4G. > > Signed-off-by: Chen Zhou > Tested-by: John Donnelly > Tested-by: Prabhakar Kushwaha > --- > Documentation/admin-guide/kdump/kdump.rst | 13 +++-- > Documentation/admin-guide/kernel-parameters.txt | 17 +++-- > 2 files changed, 26 insertions(+), 4 deletions(-) > > diff --git a/Documentation/admin-guide/kdump/kdump.rst > b/Documentation/admin-guide/kdump/kdump.rst > index 2da65fef2a1c..6ba294d425c9 100644 > --- a/Documentation/admin-guide/kdump/kdump.rst > +++ b/Documentation/admin-guide/kdump/kdump.rst > @@ -299,7 +299,13 @@ Boot into System Kernel > "crashkernel=64M@16M" tells the system kernel to reserve 64 MB of memory > starting at physical address 0x0100 (16MB) for the dump-capture > kernel. > > - On x86 and x86_64, use "crashkernel=64M@16M". > + On x86 use "crashkernel=64M@16M". > + > + On x86_64, use "crashkernel=Y[@X]" to select a region under 4G first, and > + fall back to reserve region above 4G when '@offset' hasn't been specified. Actually crashkernel=Y without the offset works well, I do not see why we need the offset, it should be some legacy thing. So it should be better just use the Y without offset here, and just leave a note somewhere people can use [@X] offset when they really have to. > + We can also use "crashkernel=X,high" to select a region above 4G, which > + also tries to allocate at least 256M below 4G automatically and > + "crashkernel=Y,low" can be used to allocate specified size low memory. > > On ppc64, use "crashkernel=128M@32M". > > @@ -316,8 +322,11 @@ Boot into System Kernel > kernel will automatically locate the crash kernel image within the > first 512MB of RAM if X is not given. > > - On arm64, use "crashkernel=Y[@X]". Note that the start address of > + On arm64, use "crashkernel=Y[@X]". Note that the start address of > the kernel, X if explicitly specified, must be aligned to 2MiB (0x20). > + If crashkernel=Z,low is specified simultaneously, reserve spcified size > + low memory for crash kdump kernel devices firstly and then reserve memory "devices" seems not very accurate, maybe just drop the "for crash kdump kernel devices" since it is clear based on the context. > + above 4G. > > Load the Dump-capture Kernel > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > b/Documentation/admin-guide/kernel-parameters.txt > index fb95fad81c79..335431a351c0 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -722,6 +722,9 @@ > [KNL, x86_64] select a region under 4G first, and > fall back to reserve region above 4G when '@offset' > hasn't been specified. > + [KNL, arm64] If crashkernel=X,low is specified, reserve > + spcified size low memory for crash kdump kernel devices Ditto. > + firstly, and then reserve memory above 4G. > See Documentation/admin-guide/kdump/kdump.rst for > further details. > > crashkernel=range1:size1[,range2:size2,...][@offset] > @@ -746,13 +749,23 @@ > requires at least 64M+32K low memory, also enough extra > low memory is needed to make sure DMA buffers for 32-bit > devices won't run out. Kernel would try to allocate at > - at least 256M below 4G automatically. > + least 256M below 4G automatically. > This one let user to specify own low range under 4G > for second kernel instead. > 0: to disable low allocation. > It will be ignored when crashkernel=X,high is not used > or memory reserved is below 4G. > - > + [KNL, arm64] range under 4G. > + This one let user to specify own low range under 4G > + for crash dump kernel instead. > + Different with x86_64, kernel allocates specified size sounds better: s/Different with/Be different from s/allocates/reserves > + physical memory region only when this parameter is > specified > + instead of trying to allocate at least 256M below 4G s/allocate/reserve > + automatically. > + This parameter is used along with crashkernel=X when we Could change the passive sentence to below: "Use this parameter along with" > + want to reserve crashkernel above 4G. If there are > devices > + need to use ZONE_DMA in crash dump
Re: [PATCH 1/8] cpufreq: allow drivers to flag custom support for freq invariance
On 01-07-20, 18:05, Rafael J. Wysocki wrote: > On Wed, Jul 1, 2020 at 3:33 PM Ionela Voinescu > wrote: > > On Wednesday 01 Jul 2020 at 16:16:17 (+0530), Viresh Kumar wrote: > > > I will rather suggest CPUFREQ_SKIP_SET_FREQ_SCALE as the name and > > > functionality. We need to give drivers a choice if they do not want > > > the core to do it on their behalf, because they are doing it on their > > > own or they don't want to do it. > > Well, this would go backwards to me, as we seem to be designing an > opt-out flag for something that's not even implemented already. > > I would go for an opt-in instead. That would be much cleaner and less > prone to regressions IMO. That's fine, I just wanted an option for drivers to opt-out of this thing. I felt okay with the opt-out flag as this should be enabled for most of the drivers and so enabling by default looked okay as well. > > In this case we would not be able to tell if cpufreq (driver or core) > > can provide the frequency scale factor, so we would not be able to tell > > if the system is really frequency invariant; CPUFREQ_SKIP_SET_FREQ_SCALE That is easy to fix. Let the drivers call enable_cpufreq_freq_invariance() and set the flag. > > would be set if either: > > - the driver calls arch_set_freq_scale() on its own > > - the driver does not want arch_set_freq_scale() to be called. > > > > So at the core level we would not be able to distinguish between the > > two, and return whether cpufreq-based invariance is supported. > > > > I don't really see a reason why a driver would not want to set the > > frequency scale factor A simple case where the driver doesn't have any idea what the real freq of the CPU is and it doesn't have counters to guess it as well. There can be other reasons which we aren't able to imagine at this point of time. -- viresh
[PATCH v8 1/4] kasan: define and use MAX_PTRS_PER_* for early shadow tables
powerpc has a variable number of PTRS_PER_*, set at runtime based
on the MMU that the kernel is booted under.
This means the PTRS_PER_* are no longer constants, and therefore
breaks the build.
Define default MAX_PTRS_PER_*s in the same style as MAX_PTRS_PER_P4D.
As KASAN is the only user at the moment, just define them in the kasan
header, and have them default to PTRS_PER_* unless overridden in arch
code.
Suggested-by: Christophe Leroy
Suggested-by: Balbir Singh
Reviewed-by: Christophe Leroy
Reviewed-by: Balbir Singh
Signed-off-by: Daniel Axtens
---
include/linux/kasan.h | 18 +++---
mm/kasan/init.c | 6 +++---
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index 82522e996c76..b6f94952333b 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -14,10 +14,22 @@ struct task_struct;
#include
#include
+#ifndef MAX_PTRS_PER_PTE
+#define MAX_PTRS_PER_PTE PTRS_PER_PTE
+#endif
+
+#ifndef MAX_PTRS_PER_PMD
+#define MAX_PTRS_PER_PMD PTRS_PER_PMD
+#endif
+
+#ifndef MAX_PTRS_PER_PUD
+#define MAX_PTRS_PER_PUD PTRS_PER_PUD
+#endif
+
extern unsigned char kasan_early_shadow_page[PAGE_SIZE];
-extern pte_t kasan_early_shadow_pte[PTRS_PER_PTE];
-extern pmd_t kasan_early_shadow_pmd[PTRS_PER_PMD];
-extern pud_t kasan_early_shadow_pud[PTRS_PER_PUD];
+extern pte_t kasan_early_shadow_pte[MAX_PTRS_PER_PTE];
+extern pmd_t kasan_early_shadow_pmd[MAX_PTRS_PER_PMD];
+extern pud_t kasan_early_shadow_pud[MAX_PTRS_PER_PUD];
extern p4d_t kasan_early_shadow_p4d[MAX_PTRS_PER_P4D];
int kasan_populate_early_shadow(const void *shadow_start,
diff --git a/mm/kasan/init.c b/mm/kasan/init.c
index fe6be0be1f76..42bca3d27db8 100644
--- a/mm/kasan/init.c
+++ b/mm/kasan/init.c
@@ -46,7 +46,7 @@ static inline bool kasan_p4d_table(pgd_t pgd)
}
#endif
#if CONFIG_PGTABLE_LEVELS > 3
-pud_t kasan_early_shadow_pud[PTRS_PER_PUD] __page_aligned_bss;
+pud_t kasan_early_shadow_pud[MAX_PTRS_PER_PUD] __page_aligned_bss;
static inline bool kasan_pud_table(p4d_t p4d)
{
return p4d_page(p4d) == virt_to_page(lm_alias(kasan_early_shadow_pud));
@@ -58,7 +58,7 @@ static inline bool kasan_pud_table(p4d_t p4d)
}
#endif
#if CONFIG_PGTABLE_LEVELS > 2
-pmd_t kasan_early_shadow_pmd[PTRS_PER_PMD] __page_aligned_bss;
+pmd_t kasan_early_shadow_pmd[MAX_PTRS_PER_PMD] __page_aligned_bss;
static inline bool kasan_pmd_table(pud_t pud)
{
return pud_page(pud) == virt_to_page(lm_alias(kasan_early_shadow_pmd));
@@ -69,7 +69,7 @@ static inline bool kasan_pmd_table(pud_t pud)
return false;
}
#endif
-pte_t kasan_early_shadow_pte[PTRS_PER_PTE] __page_aligned_bss;
+pte_t kasan_early_shadow_pte[MAX_PTRS_PER_PTE] __page_aligned_bss;
static inline bool kasan_pte_table(pmd_t pmd)
{
--
2.25.1
[PATCH v8 0/4] KASAN for powerpc64 radix
Building on the work of Christophe, Aneesh and Balbir, I've ported
KASAN to 64-bit Book3S kernels running on the Radix MMU.
This provides full inline instrumentation on radix, but does require
that you be able to specify the amount of physically contiguous memory
on the system at compile time. More details in patch 4.
v8 is just a rebase of v7 on a more recent powerpc/merge and a fixup
of a whitespace error.
Module globals still don't work, but that's due to some 'clever'
renaming of a section that the powerpc module loading code does to
avoid more complicated relocations/tramplines rather than anything to
do with KASAN.
Daniel Axtens (4):
kasan: define and use MAX_PTRS_PER_* for early shadow tables
kasan: Document support on 32-bit powerpc
powerpc/mm/kasan: rename kasan_init_32.c to init_32.c
powerpc: Book3S 64-bit "heavyweight" KASAN support
Documentation/dev-tools/kasan.rst | 8 +-
Documentation/powerpc/kasan.txt | 122 ++
arch/powerpc/Kconfig | 3 +-
arch/powerpc/Kconfig.debug| 23 +++-
arch/powerpc/Makefile | 11 ++
arch/powerpc/include/asm/book3s/64/hash.h | 4 +
arch/powerpc/include/asm/book3s/64/pgtable.h | 7 +
arch/powerpc/include/asm/book3s/64/radix.h| 5 +
arch/powerpc/include/asm/kasan.h | 11 +-
arch/powerpc/kernel/Makefile | 2 +
arch/powerpc/kernel/process.c | 16 ++-
arch/powerpc/kernel/prom.c| 76 ++-
arch/powerpc/mm/kasan/Makefile| 3 +-
.../mm/kasan/{kasan_init_32.c => init_32.c} | 0
arch/powerpc/mm/kasan/init_book3s_64.c| 73 +++
arch/powerpc/mm/ptdump/ptdump.c | 10 +-
arch/powerpc/platforms/Kconfig.cputype| 1 +
include/linux/kasan.h | 18 ++-
mm/kasan/init.c | 6 +-
19 files changed, 377 insertions(+), 22 deletions(-)
create mode 100644 Documentation/powerpc/kasan.txt
rename arch/powerpc/mm/kasan/{kasan_init_32.c => init_32.c} (100%)
create mode 100644 arch/powerpc/mm/kasan/init_book3s_64.c
--
2.25.1
[PATCH v8 4/4] powerpc: Book3S 64-bit "heavyweight" KASAN support
Implement a limited form of KASAN for Book3S 64-bit machines running under
the Radix MMU:
- Set aside the last 1/8th of the first contiguous block of physical
memory to provide writable shadow for the linear map. For annoying
reasons documented below, the memory size must be specified at compile
time.
- Enable the compiler instrumentation to check addresses and maintain the
shadow region. (This is the guts of KASAN which we can easily reuse.)
- Require kasan-vmalloc support to handle modules and anything else in
vmalloc space.
- KASAN needs to be able to validate all pointer accesses, but we can't
back all kernel addresses with real memory - only linear map and
vmalloc. On boot, set up a single page of read-only shadow that marks
all these accesses as valid.
- Make our stack-walking code KASAN-safe by using READ_ONCE_NOCHECK -
generic code, arm64, s390 and x86 all do this for similar sorts of
reasons: when unwinding a stack, we might touch memory that KASAN has
marked as being out-of-bounds. In our case we often get this when
checking for an exception frame because we're checking an arbitrary
offset into the stack frame.
See commit 20955746320e ("s390/kasan: avoid false positives during stack
unwind"), commit bcaf669b4bdb ("arm64: disable kasan when accessing
frame->fp in unwind_frame"), commit 91e08ab0c851 ("x86/dumpstack:
Prevent KASAN false positive warnings") and commit 6e22c8366416
("tracing, kasan: Silence Kasan warning in check_stack of stack_tracer")
- Document KASAN in both generic and powerpc docs.
Background
--
KASAN support on Book3S is a bit tricky to get right:
- It would be good to support inline instrumentation so as to be able to
catch stack issues that cannot be caught with outline mode.
- Inline instrumentation requires a fixed offset.
- Book3S runs code in real mode after booting. Most notably a lot of KVM
runs in real mode, and it would be good to be able to instrument it.
- Because code runs in real mode after boot, the offset has to point to
valid memory both in and out of real mode.
[ppc64 mm note: The kernel installs a linear mapping at effective
address c000... onward. This is a one-to-one mapping with physical
memory from ... onward. Because of how memory accesses work on
powerpc 64-bit Book3S, a kernel pointer in the linear map accesses the
same memory both with translations on (accessing as an 'effective
address'), and with translations off (accessing as a 'real
address'). This works in both guests and the hypervisor. For more
details, see s5.7 of Book III of version 3 of the ISA, in particular
the Storage Control Overview, s5.7.3, and s5.7.5 - noting that this
KASAN implementation currently only supports Radix.]
One approach is just to give up on inline instrumentation. This way all
checks can be delayed until after everything set is up correctly, and the
address-to-shadow calculations can be overridden. However, the features and
speed boost provided by inline instrumentation are worth trying to do
better.
If _at compile time_ it is known how much contiguous physical memory a
system has, the top 1/8th of the first block of physical memory can be set
aside for the shadow. This is a big hammer and comes with 3 big
consequences:
- there's no nice way to handle physically discontiguous memory, so only
the first physical memory block can be used.
- kernels will simply fail to boot on machines with less memory than
specified when compiling.
- kernels running on machines with more memory than specified when
compiling will simply ignore the extra memory.
Despite the limitations, it can still find bugs,
e.g. http://patchwork.ozlabs.org/patch/1103775/
At the moment, this physical memory limit must be set _even for outline
mode_. This may be changed in a later series - a different implementation
could be added for outline mode that dynamically allocates shadow at a
fixed offset. For example, see https://patchwork.ozlabs.org/patch/795211/
Suggested-by: Michael Ellerman
Cc: Balbir Singh # ppc64 out-of-line radix version
Cc: Christophe Leroy # ppc32 version
Reviewed-by: # focussed mainly on Documentation
and things impacting PPC32
Signed-off-by: Daniel Axtens
---
Documentation/dev-tools/kasan.rst| 9 +-
Documentation/powerpc/kasan.txt | 112 ++-
arch/powerpc/Kconfig | 3 +-
arch/powerpc/Kconfig.debug | 23 +++-
arch/powerpc/Makefile| 11 ++
arch/powerpc/include/asm/book3s/64/hash.h| 4 +
arch/powerpc/include/asm/book3s/64/pgtable.h | 7 ++
arch/powerpc/include/asm/book3s/64/radix.h | 5 +
arch/powerpc/include/asm/kasan.h | 11 +-
arch/powerpc/kernel/Makefile | 2 +
arch/powerpc/kernel/process.c| 16 +--
[PATCH v8 3/4] powerpc/mm/kasan: rename kasan_init_32.c to init_32.c
kasan is already implied by the directory name, we don't need to
repeat it.
Suggested-by: Christophe Leroy
Signed-off-by: Daniel Axtens
---
arch/powerpc/mm/kasan/Makefile | 2 +-
arch/powerpc/mm/kasan/{kasan_init_32.c => init_32.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename arch/powerpc/mm/kasan/{kasan_init_32.c => init_32.c} (100%)
diff --git a/arch/powerpc/mm/kasan/Makefile b/arch/powerpc/mm/kasan/Makefile
index bb1a5408b86b..42fb628a44fd 100644
--- a/arch/powerpc/mm/kasan/Makefile
+++ b/arch/powerpc/mm/kasan/Makefile
@@ -2,6 +2,6 @@
KASAN_SANITIZE := n
-obj-$(CONFIG_PPC32) += kasan_init_32.o
+obj-$(CONFIG_PPC32) += init_32.o
obj-$(CONFIG_PPC_8xx) += 8xx.o
obj-$(CONFIG_PPC_BOOK3S_32)+= book3s_32.o
diff --git a/arch/powerpc/mm/kasan/kasan_init_32.c
b/arch/powerpc/mm/kasan/init_32.c
similarity index 100%
rename from arch/powerpc/mm/kasan/kasan_init_32.c
rename to arch/powerpc/mm/kasan/init_32.c
--
2.25.1
[PATCH v8 2/4] kasan: Document support on 32-bit powerpc
KASAN is supported on 32-bit powerpc and the docs should reflect this. Document s390 support while we're at it. Suggested-by: Christophe Leroy Reviewed-by: Christophe Leroy Signed-off-by: Daniel Axtens --- Documentation/dev-tools/kasan.rst | 7 +-- Documentation/powerpc/kasan.txt | 12 2 files changed, 17 insertions(+), 2 deletions(-) create mode 100644 Documentation/powerpc/kasan.txt diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index c652d740735d..554cbee1d240 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -22,7 +22,8 @@ global variables yet. Tag-based KASAN is only supported in Clang and requires version 7.0.0 or later. Currently generic KASAN is supported for the x86_64, arm64, xtensa, s390 and -riscv architectures, and tag-based KASAN is supported only for arm64. +riscv architectures. It is also supported on 32-bit powerpc kernels. Tag-based +KASAN is supported only on arm64. Usage - @@ -255,7 +256,9 @@ CONFIG_KASAN_VMALLOC With ``CONFIG_KASAN_VMALLOC``, KASAN can cover vmalloc space at the -cost of greater memory usage. Currently this is only supported on x86. +cost of greater memory usage. Currently this supported on x86, s390 +and 32-bit powerpc. It is optional, except on 32-bit powerpc kernels +with module support, where it is required. This works by hooking into vmalloc and vmap, and dynamically allocating real shadow memory to back the mappings. diff --git a/Documentation/powerpc/kasan.txt b/Documentation/powerpc/kasan.txt new file mode 100644 index ..26bb0e8bb18c --- /dev/null +++ b/Documentation/powerpc/kasan.txt @@ -0,0 +1,12 @@ +KASAN is supported on powerpc on 32-bit only. + +32 bit support +== + +KASAN is supported on both hash and nohash MMUs on 32-bit. + +The shadow area sits at the top of the kernel virtual memory space above the +fixmap area and occupies one eighth of the total kernel virtual memory space. + +Instrumentation of the vmalloc area is optional, unless built with modules, +in which case it is required. -- 2.25.1
Re: [V2 PATCH] usb: mtu3: fix NULL pointer dereference
On Wed, 2020-07-01 at 13:58 +0200, Greg Kroah-Hartman wrote:
> On Tue, Jun 30, 2020 at 03:42:22PM +0800, Chunfeng Yun wrote:
> > Some pointers are dereferenced before successful checks.
> >
> > Reported-by: Markus Elfring
> > Signed-off-by: Chunfeng Yun
> > ---
> > v2: nothing changed, but abandon another patch
> > ---
> > drivers/usb/mtu3/mtu3_gadget.c | 25 ++---
> > 1 file changed, 18 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/usb/mtu3/mtu3_gadget.c b/drivers/usb/mtu3/mtu3_gadget.c
> > index f93732e..1689ca8 100644
> > --- a/drivers/usb/mtu3/mtu3_gadget.c
> > +++ b/drivers/usb/mtu3/mtu3_gadget.c
> > @@ -332,14 +332,21 @@ static int mtu3_gadget_queue(struct usb_ep *ep,
> >
> > static int mtu3_gadget_dequeue(struct usb_ep *ep, struct usb_request *req)
> > {
> > - struct mtu3_ep *mep = to_mtu3_ep(ep);
> > - struct mtu3_request *mreq = to_mtu3_request(req);
> > + struct mtu3_ep *mep;
> > + struct mtu3_request *mreq;
> > struct mtu3_request *r;
> > + struct mtu3 *mtu;
> > unsigned long flags;
> > int ret = 0;
> > - struct mtu3 *mtu = mep->mtu;
> >
> > - if (!ep || !req || mreq->mep != mep)
> > + if (!ep || !req)
> > + return -EINVAL;
>
> How will either of those ever be NULL? The kernel will not call this
> function with either of them being NULL, right?
Yes, I find all class drivers already ensure they are not NULL.
>
> > +
> > + mep = to_mtu3_ep(ep);
> > + mtu = mep->mtu;
> > +
> > + mreq = to_mtu3_request(req);
> > + if (mreq->mep != mep)
> > return -EINVAL;
> >
> > dev_dbg(mtu->dev, "%s : req=%p\n", __func__, req);
> > @@ -373,8 +380,8 @@ static int mtu3_gadget_dequeue(struct usb_ep *ep,
> > struct usb_request *req)
> > */
> > static int mtu3_gadget_ep_set_halt(struct usb_ep *ep, int value)
> > {
> > - struct mtu3_ep *mep = to_mtu3_ep(ep);
> > - struct mtu3 *mtu = mep->mtu;
> > + struct mtu3_ep *mep;
> > + struct mtu3 *mtu;
> > struct mtu3_request *mreq;
> > unsigned long flags;
> > int ret = 0;
> > @@ -382,6 +389,9 @@ static int mtu3_gadget_ep_set_halt(struct usb_ep *ep,
> > int value)
> > if (!ep)
> > return -EINVAL;
>
> Same here, how can that ever happen?
Maybe when the class driver has something wrong:)
You mean it's better to remove these unnecessary checks?
Thanks
>
> >
> > + mep = to_mtu3_ep(ep);
> > + mtu = mep->mtu;
> > +
> > dev_dbg(mtu->dev, "%s : %s...", __func__, ep->name);
> >
> > spin_lock_irqsave(>lock, flags);
> > @@ -422,11 +432,12 @@ static int mtu3_gadget_ep_set_halt(struct usb_ep *ep,
> > int value)
> > /* Sets the halt feature with the clear requests ignored */
> > static int mtu3_gadget_ep_set_wedge(struct usb_ep *ep)
> > {
> > - struct mtu3_ep *mep = to_mtu3_ep(ep);
> > + struct mtu3_ep *mep;
> >
> > if (!ep)
> > return -EINVAL;
>
> Again, same here.
>
> thanks,
>
> greg k-h
Re: [PATCH v9 1/5] x86: kdump: move reserve_crashkernel_low() into crash_core.c
On 06/28/20 at 04:34pm, Chen Zhou wrote:
> In preparation for supporting reserve_crashkernel_low in arm64 as
> x86_64 does, move reserve_crashkernel_low() into kernel/crash_core.c.
>
> BTW, move x86_64 CRASH_ALIGN to 2M suggested by Dave. CONFIG_PHYSICAL_ALIGN
> can be selected from 2M to 16M, move to the same as arm64.
>
> Note, in arm64, we reserve low memory if and only if crashkernel=X,low
> is specified. Different with x86_64, don't set low memory automatically.
>
> Reported-by: kbuild test robot
> Signed-off-by: Chen Zhou
> Tested-by: John Donnelly
> Tested-by: Prabhakar Kushwaha
> ---
> arch/x86/kernel/setup.c| 66 -
> include/linux/crash_core.h | 3 ++
> include/linux/kexec.h | 2 -
> kernel/crash_core.c| 85 ++
> kernel/kexec_core.c| 17
> 5 files changed, 96 insertions(+), 77 deletions(-)
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index a3767e74c758..33db99ae3035 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -401,8 +401,8 @@ static void __init
> memblock_x86_reserve_range_setup_data(void)
>
> #ifdef CONFIG_KEXEC_CORE
>
> -/* 16M alignment for crash kernel regions */
> -#define CRASH_ALIGN SZ_16M
> +/* 2M alignment for crash kernel regions */
> +#define CRASH_ALIGN SZ_2M
>
> /*
> * Keep the crash kernel below this limit.
> @@ -425,59 +425,6 @@ static void __init
> memblock_x86_reserve_range_setup_data(void)
> # define CRASH_ADDR_HIGH_MAX SZ_64T
> #endif
>
> -static int __init reserve_crashkernel_low(void)
> -{
> -#ifdef CONFIG_X86_64
> - unsigned long long base, low_base = 0, low_size = 0;
> - unsigned long total_low_mem;
> - int ret;
> -
> - total_low_mem = memblock_mem_size(1UL << (32 - PAGE_SHIFT));
> -
> - /* crashkernel=Y,low */
> - ret = parse_crashkernel_low(boot_command_line, total_low_mem,
> _size, );
> - if (ret) {
> - /*
> - * two parts from kernel/dma/swiotlb.c:
> - * -swiotlb size: user-specified with swiotlb= or default.
> - *
> - * -swiotlb overflow buffer: now hardcoded to 32k. We round it
> - * to 8M for other buffers that may need to stay low too. Also
> - * make sure we allocate enough extra low memory so that we
> - * don't run out of DMA buffers for 32-bit devices.
> - */
> - low_size = max(swiotlb_size_or_default() + (8UL << 20), 256UL
> << 20);
> - } else {
> - /* passed with crashkernel=0,low ? */
> - if (!low_size)
> - return 0;
> - }
> -
> - low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
> - if (!low_base) {
> - pr_err("Cannot reserve %ldMB crashkernel low memory, please try
> smaller size.\n",
> -(unsigned long)(low_size >> 20));
> - return -ENOMEM;
> - }
> -
> - ret = memblock_reserve(low_base, low_size);
> - if (ret) {
> - pr_err("%s: Error reserving crashkernel low memblock.\n",
> __func__);
> - return ret;
> - }
> -
> - pr_info("Reserving %ldMB of low memory at %ldMB for crashkernel (System
> low RAM: %ldMB)\n",
> - (unsigned long)(low_size >> 20),
> - (unsigned long)(low_base >> 20),
> - (unsigned long)(total_low_mem >> 20));
> -
> - crashk_low_res.start = low_base;
> - crashk_low_res.end = low_base + low_size - 1;
> - insert_resource(_resource, _low_res);
> -#endif
> - return 0;
> -}
> -
> static void __init reserve_crashkernel(void)
> {
> unsigned long long crash_size, crash_base, total_mem;
> @@ -541,9 +488,12 @@ static void __init reserve_crashkernel(void)
> return;
> }
>
> - if (crash_base >= (1ULL << 32) && reserve_crashkernel_low()) {
> - memblock_free(crash_base, crash_size);
> - return;
> + if (crash_base >= (1ULL << 32)) {
> + if (reserve_crashkernel_low()) {
> + memblock_free(crash_base, crash_size);
> + return;
> + }
> + insert_resource(_resource, _low_res);
> }
>
> pr_info("Reserving %ldMB of memory at %ldMB for crashkernel (System
> RAM: %ldMB)\n",
> diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
> index 525510a9f965..4df8c0bff03e 100644
> --- a/include/linux/crash_core.h
> +++ b/include/linux/crash_core.h
> @@ -63,6 +63,8 @@ phys_addr_t paddr_vmcoreinfo_note(void);
> extern unsigned char *vmcoreinfo_data;
> extern size_t vmcoreinfo_size;
> extern u32 *vmcoreinfo_note;
> +extern struct resource crashk_res;
> +extern struct resource crashk_low_res;
>
> Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
> void *data, size_t data_len);
> @@ -74,5 +76,6 @@
Re: [PATCH] clk: mvebu: ARMADA_AP_CPU_CLK needs to select ARMADA_AP_CP_HELPER
On 01-07-20, 13:11, Nathan Chancellor wrote:
> When building arm32 allmodconfig:
>
> ld.lld: error: undefined symbol: ap_cp_unique_name
> >>> referenced by ap-cpu-clk.c
> >>> clk/mvebu/ap-cpu-clk.o:(ap_cpu_clock_probe) in archive
> >>> drivers/built-in.a
>
> ap_cp_unique_name is only compiled into the kernel image when
> CONFIG_ARMADA_AP_CP_HELPER is selected (as it is not user selectable).
> However, CONFIG_ARMADA_AP_CPU_CLK does not select it.
>
> This has been a problem since the driver was added to the kernel but it
> was not built before commit c318ea261749 ("cpufreq: ap806: fix cpufreq
> driver needs ap cpu clk") so it was never noticed.
>
> Fixes: f756e362d938 ("clk: mvebu: add CPU clock driver for Armada 7K/8K")
> Signed-off-by: Nathan Chancellor
> ---
>
> I do not know who should actually take this patch since the problematic
> patch is on Viresh's cpufreq/arm/linux-next
That patch just enabled the config option and I have picked it up for
5.9.
> but the problem originated
> from a patch in the clk tree in 5.4. I assume all that would be needed
> is a clk maintainer's ack? Please let me know if I did something wrong.
This patch should go through clk tree and get pushed for 5.8 if
possible (which makes sense as well).
--
viresh
Re: [PATCH] kbuild: do not export LDFLAGS_vmlinux
On Thu, Jul 2, 2020 at 5:14 AM Max Filippov wrote: > > On Wed, Jul 1, 2020 at 12:30 PM Masahiro Yamada wrote: > > [...] > > > diff --git a/arch/xtensa/boot/boot-elf/Makefile > > b/arch/xtensa/boot/boot-elf/Makefile > > index 12ae1e91cb75..c6538d3321b9 100644 > > --- a/arch/xtensa/boot/boot-elf/Makefile > > +++ b/arch/xtensa/boot/boot-elf/Makefile > > @@ -25,7 +25,7 @@ $(obj)/Image.o: vmlinux.bin $(OBJS) > > $(OBJS) $@ > > > > $(obj)/../Image.elf: $(obj)/Image.o $(obj)/boot.lds > > - $(Q)$(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_vmlinux) \ > > + $(LD) $(KBUILD_LDFLAGS) \ > > Can that $(Q) be retained, please? > The rest LGTM. Oops, I temporarily deleted $(Q) for debugging, then accidentally committed it. I will restore $(Q) when this patch is applied. Thanks. > > -T $(obj)/boot.lds \ > > --build-id=none \ > > -o $@ $(obj)/Image.o > > -- > Thanks. > -- Max -- Best Regards Masahiro Yamada
Re: [PATCH 1/2] iommu: Add iommu_group_get/set_domain()
Hi Robin, On 7/1/20 8:18 PM, Robin Murphy wrote: On 2020-07-01 08:32, Lu Baolu wrote: Hi Robin, On 2020/7/1 0:51, Robin Murphy wrote: On 2020-06-30 02:03, Lu Baolu wrote: Hi Robin, On 6/29/20 7:56 PM, Robin Murphy wrote: On 2020-06-27 04:15, Lu Baolu wrote: The hardware assistant vfio mediated device is a use case of iommu aux-domain. The interactions between vfio/mdev and iommu during mdev creation and passthr are: - Create a group for mdev with iommu_group_alloc(); - Add the device to the group with group = iommu_group_alloc(); if (IS_ERR(group)) return PTR_ERR(group); ret = iommu_group_add_device(group, >dev); if (!ret) dev_info(>dev, "MDEV: group_id = %d\n", iommu_group_id(group)); - Allocate an aux-domain iommu_domain_alloc() - Attach the aux-domain to the physical device from which the mdev is created. iommu_aux_attach_device() In the whole process, an iommu group was allocated for the mdev and an iommu domain was attached to the group, but the group->domain leaves NULL. As the result, iommu_get_domain_for_dev() doesn't work anymore. This adds iommu_group_get/set_domain() so that group->domain could be managed whenever a domain is attached or detached through the aux-domain api's. Letting external callers poke around directly in the internals of iommu_group doesn't look right to me. Unfortunately, it seems that the vifo iommu abstraction is deeply bound to the IOMMU subsystem. We can easily find other examples: iommu_group_get/set_iommudata() iommu_group_get/set_name() ... Sure, but those are ways for users of a group to attach useful information of their own to it, that doesn't matter to the IOMMU subsystem itself. The interface you've proposed gives callers rich new opportunities to fundamentally break correct operation of the API: dom = iommu_domain_alloc(); iommu_attach_group(dom, grp); ... iommu_group_set_domain(grp, NULL); // oops, leaked and can't ever detach properly now or perhaps: grp = iommu_group_alloc(); iommu_group_add_device(grp, dev); iommu_group_set_domain(grp, dom); ... iommu_detach_group(dom, grp); // oops, IOMMU driver might not handle this If a regular device is attached to one or more aux domains for PASID use, iommu_get_domain_for_dev() is still going to return the primary domain, so why should it be expected to behave differently for mediated Unlike the normal device attach, we will encounter two devices when it comes to aux-domain. - Parent physical device - this might be, for example, a PCIe device with PASID feature support, hence it is able to tag an unique PASID for DMA transfers originated from its subset. The device driver hence is able to wrapper this subset into an isolated: - Mediated device - a fake device created by the device driver mentioned above. Yes. All you mentioned are right for the parent device. But for mediated device, iommu_get_domain_for_dev() doesn't work even it has an valid iommu_group and iommu_domain. iommu_get_domain_for_dev() is a necessary interface for device drivers which want to support aux-domain. For example, Only if they want to follow this very specific notion of using made-up devices and groups to represent aux attachments. Even if a driver managing its own aux domains entirely privately does create child devices for them, it's not like it can't keep its domain pointers in drvdata if it wants to ;) Let's not conflate the current implementation of vfio_mdev with the general concepts involved here. struct iommu_domain *domain; struct device *dev = mdev_dev(mdev); unsigned long pasid; domain = iommu_get_domain_for_dev(dev); if (!domain) return -ENODEV; pasid = iommu_aux_get_pasid(domain, dev->parent); if (pasid == IOASID_INVALID) return -EINVAL; /* Program the device context with the PASID value */ Without this fix, iommu_get_domain_for_dev() always returns NULL and the device driver has no means to support aux-domain. So either the IOMMU API itself is missing the ability to do the right thing internally, or the mdev layer isn't using it appropriately. Either way, simply punching holes in the API for mdev to hack around its own mess doesn't seem like the best thing to do. The initial impression I got was that it's implicitly assumed here that the mdev itself is attached to exactly one aux domain and nothing else, at which point I would wonder why it's using aux at all, but are you saying that in fact no attach happens with the mdev group either way, only to the parent device? I'll admit I'm not hugely familiar with any of this, but it seems to me that the logical flow should be: - allocate domain - attach as aux to parent - retrieve aux domain PASID - create mdev
RE: [PATCH V4 2/5] clk: imx: Add clock configuration for ARMv7 platforms
> From: Anson Huang > Sent: Thursday, July 2, 2020 10:15 AM > > Add CONFIG_CLK_xxx for i.MX ARMv7 platforms, and use it as build option > instead of CONFIG_SOC_xxx, the CONFIG_CLK_xxx will be selected by default > according to CONFIG_SOC_xxx. > > Signed-off-by: Anson Huang Reviewed-by: Dong Aisheng Regards Aisheng > --- > Changes since V3: > - Add clock configuration for each ARMv7. > --- > drivers/clk/imx/Kconfig | 90 > > drivers/clk/imx/Makefile | 30 > 2 files changed, 105 insertions(+), 15 deletions(-) > > diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index > db0253f..09fc8ad 100644 > --- a/drivers/clk/imx/Kconfig > +++ b/drivers/clk/imx/Kconfig > @@ -8,6 +8,96 @@ config MXC_CLK_SCU > bool > depends on IMX_SCU > > +config CLK_IMX1 > + bool "IMX1 CCM Clock Driver" > + depends on SOC_IMX1 || COMPILE_TEST > + default SOC_IMX1 > + select MXC_CLK > + > +config CLK_IMX21 > + bool "IMX21 CCM Clock Driver" > + depends on SOC_IMX21 || COMPILE_TEST > + default SOC_IMX21 > + select MXC_CLK > + > +config CLK_IMX25 > + bool "IMX25 CCM Clock Driver" > + depends on SOC_IMX25 || COMPILE_TEST > + default SOC_IMX25 > + select MXC_CLK > + > +config CLK_IMX27 > + bool "IMX27 CCM Clock Driver" > + depends on SOC_IMX27 || COMPILE_TEST > + default SOC_IMX27 > + select MXC_CLK > + > +config CLK_IMX31 > + bool "IMX31 CCM Clock Driver" > + depends on SOC_IMX31 || COMPILE_TEST > + default SOC_IMX31 > + select MXC_CLK > + > +config CLK_IMX35 > + bool "IMX35 CCM Clock Driver" > + depends on SOC_IMX35 || COMPILE_TEST > + default SOC_IMX35 > + select MXC_CLK > + > +config CLK_IMX5 > + bool "IMX5 CCM Clock Driver" > + depends on SOC_IMX5 || COMPILE_TEST > + default SOC_IMX5 > + select MXC_CLK > + > +config CLK_IMX6Q > + bool "IMX6Q CCM Clock Driver" > + depends on SOC_IMX6Q || COMPILE_TEST > + default SOC_IMX6Q > + select MXC_CLK > + > +config CLK_IMX6SL > + bool "IMX6SL CCM Clock Driver" > + depends on SOC_IMX6SL || COMPILE_TEST > + default SOC_IMX6SL > + select MXC_CLK > + > +config CLK_IMX6SLL > + bool "IMX6SLL CCM Clock Driver" > + depends on SOC_IMX6SLL || COMPILE_TEST > + default SOC_IMX6SLL > + select MXC_CLK > + > +config CLK_IMX6SX > + bool "IMX6SX CCM Clock Driver" > + depends on SOC_IMX6SX || COMPILE_TEST > + default SOC_IMX6SX > + select MXC_CLK > + > +config CLK_IMX6UL > + bool "IMX6UL CCM Clock Driver" > + depends on SOC_IMX6UL || COMPILE_TEST > + default SOC_IMX6UL > + select MXC_CLK > + > +config CLK_IMX7D > + bool "IMX7D CCM Clock Driver" > + depends on SOC_IMX7D || COMPILE_TEST > + default SOC_IMX7D > + select MXC_CLK > + > +config CLK_IMX7ULP > + bool "IMX7ULP Clock Driver" > + depends on SOC_IMX7ULP || COMPILE_TEST > + default SOC_IMX7ULP > + select MXC_CLK > + > +config CLK_VF610 > + bool "VF610 Clock Driver" > + depends on SOC_VF610 || COMPILE_TEST > + default SOC_VF610 > + select MXC_CLK > + > config CLK_IMX8MM > bool "IMX8MM CCM Clock Driver" > depends on ARCH_MXC > diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile index > 928f874..394ade7 100644 > --- a/drivers/clk/imx/Makefile > +++ b/drivers/clk/imx/Makefile > @@ -31,18 +31,18 @@ obj-$(CONFIG_CLK_IMX8MP) += clk-imx8mp.o > obj-$(CONFIG_CLK_IMX8MQ) += clk-imx8mq.o > obj-$(CONFIG_CLK_IMX8QXP) += clk-imx8qxp.o clk-imx8qxp-lpcg.o > > -obj-$(CONFIG_SOC_IMX1) += clk-imx1.o > -obj-$(CONFIG_SOC_IMX21) += clk-imx21.o > -obj-$(CONFIG_SOC_IMX25) += clk-imx25.o > -obj-$(CONFIG_SOC_IMX27) += clk-imx27.o > -obj-$(CONFIG_SOC_IMX31) += clk-imx31.o > -obj-$(CONFIG_SOC_IMX35) += clk-imx35.o > -obj-$(CONFIG_SOC_IMX5) += clk-imx5.o > -obj-$(CONFIG_SOC_IMX6Q) += clk-imx6q.o > -obj-$(CONFIG_SOC_IMX6SL) += clk-imx6sl.o > -obj-$(CONFIG_SOC_IMX6SLL) += clk-imx6sll.o > -obj-$(CONFIG_SOC_IMX6SX) += clk-imx6sx.o > -obj-$(CONFIG_SOC_IMX6UL) += clk-imx6ul.o > -obj-$(CONFIG_SOC_IMX7D) += clk-imx7d.o > -obj-$(CONFIG_SOC_IMX7ULP) += clk-imx7ulp.o > -obj-$(CONFIG_SOC_VF610) += clk-vf610.o > +obj-$(CONFIG_CLK_IMX1) += clk-imx1.o > +obj-$(CONFIG_CLK_IMX21) += clk-imx21.o > +obj-$(CONFIG_CLK_IMX25) += clk-imx25.o > +obj-$(CONFIG_CLK_IMX27) += clk-imx27.o > +obj-$(CONFIG_CLK_IMX31) += clk-imx31.o > +obj-$(CONFIG_CLK_IMX35) += clk-imx35.o > +obj-$(CONFIG_CLK_IMX5) += clk-imx5.o > +obj-$(CONFIG_CLK_IMX6Q) += clk-imx6q.o > +obj-$(CONFIG_CLK_IMX6SL) += clk-imx6sl.o > +obj-$(CONFIG_CLK_IMX6SLL) += clk-imx6sll.o > +obj-$(CONFIG_CLK_IMX6SX) += clk-imx6sx.o >
Re: [PATCH v3] cpufreq: CPPC: simply the code access 'highest_perf' value in cppc_perf_caps struct
On 01-07-20, 14:16, Rafael J. Wysocki wrote:
> On Wed, Jul 1, 2020 at 6:52 AM Viresh Kumar wrote:
> >
> > On 01-07-20, 12:20, Xin Hao wrote:
> > > The 'caps' variable has been defined, so there is no need to get
> > > 'highest_perf' value through 'cpu->caps.highest_perf', you can use
> > > 'caps->highest_perf' instead.
> > >
> > > Signed-off-by: Xin Hao
> > > ---
> > > drivers/cpufreq/cppc_cpufreq.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/cpufreq/cppc_cpufreq.c
> > > b/drivers/cpufreq/cppc_cpufreq.c
> > > index 257d726a4456..051d0e56c67a 100644
> > > --- a/drivers/cpufreq/cppc_cpufreq.c
> > > +++ b/drivers/cpufreq/cppc_cpufreq.c
> > > @@ -161,7 +161,7 @@ static unsigned int cppc_cpufreq_perf_to_khz(struct
> > > cppc_cpudata *cpu,
> > > if (!max_khz)
> > > max_khz = cppc_get_dmi_max_khz();
> > > mul = max_khz;
> > > - div = cpu->perf_caps.highest_perf;
> > > + div = caps->highest_perf;
> > > }
> > > return (u64)perf * mul / div;
> > > }
> > > @@ -184,7 +184,7 @@ static unsigned int cppc_cpufreq_khz_to_perf(struct
> > > cppc_cpudata *cpu,
> > > } else {
> > > if (!max_khz)
> > > max_khz = cppc_get_dmi_max_khz();
> > > - mul = cpu->perf_caps.highest_perf;
> > > + mul = caps->highest_perf;
> > > div = max_khz;
> > > }
> >
> > Applied. Thanks.
>
> I applied the previous cppc_cpufreq patch, hopefully it will not clash
> with this one.
>
> Are you going to take care of this driver going forward?
I started picking up the patches for this driver as it was mostly ARM
stuff and FWIW, I picked the previous one as well and because it was
sent by me, I never replied with the "Applied" message :)
Will it be possible for you to drop that one? Or should I drop that
now ? There shouldn't be any conflicts for now though.
--
viresh
Re: objtool clac/stac handling change..
On Wed, Jul 1, 2020 at 7:30 PM Linus Torvalds wrote: > > I guess we could do that. Are there cases where this actually helps? Hmm. Thinking about it., using that approach might make the "CONFIG_CC_HAS_ASM_GOTO_OUTPUT" choices simpler to handle. With ASM_GOTO_OUTPUT it generates the perfect non-jump code. And without it, it generates the (annoying, but inevitable) actual conditionals. Linus
[PATCH 5/6] crypto: hisilicon/hpre - update debugfs interface parameters
Update debugfs interface parameters, and adjust the
processing logic inside the corresponding function.
Fixes: 848974151618("crypto: hisilicon - Add debugfs for HPRE")
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/hpre/hpre_main.c | 61 ++-
1 file changed, 27 insertions(+), 34 deletions(-)
diff --git a/drivers/crypto/hisilicon/hpre/hpre_main.c
b/drivers/crypto/hisilicon/hpre/hpre_main.c
index bfe8a91..6f7a453 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_main.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_main.c
@@ -567,15 +567,17 @@ static int hpre_debugfs_atomic64_set(void *data, u64 val)
DEFINE_DEBUGFS_ATTRIBUTE(hpre_atomic64_ops, hpre_debugfs_atomic64_get,
hpre_debugfs_atomic64_set, "%llu\n");
-static int hpre_create_debugfs_file(struct hpre_debug *dbg, struct dentry *dir,
+static int hpre_create_debugfs_file(struct hisi_qm *qm, struct dentry *dir,
enum hpre_ctrl_dbgfs_file type, int indx)
{
+ struct hpre *hpre = container_of(qm, struct hpre, qm);
+ struct hpre_debug *dbg = >debug;
struct dentry *file_dir;
if (dir)
file_dir = dir;
else
- file_dir = dbg->debug_root;
+ file_dir = qm->debug.debug_root;
if (type >= HPRE_DEBUG_FILE_NUM)
return -EINVAL;
@@ -590,10 +592,8 @@ static int hpre_create_debugfs_file(struct hpre_debug
*dbg, struct dentry *dir,
return 0;
}
-static int hpre_pf_comm_regs_debugfs_init(struct hpre_debug *debug)
+static int hpre_pf_comm_regs_debugfs_init(struct hisi_qm *qm)
{
- struct hpre *hpre = container_of(debug, struct hpre, debug);
- struct hisi_qm *qm = >qm;
struct device *dev = >pdev->dev;
struct debugfs_regset32 *regset;
@@ -605,14 +605,13 @@ static int hpre_pf_comm_regs_debugfs_init(struct
hpre_debug *debug)
regset->nregs = ARRAY_SIZE(hpre_com_dfx_regs);
regset->base = qm->io_base;
- debugfs_create_regset32("regs", 0444, debug->debug_root, regset);
+ debugfs_create_regset32("regs", 0444, qm->debug.debug_root, regset);
return 0;
}
-static int hpre_cluster_debugfs_init(struct hpre_debug *debug)
+static int hpre_cluster_debugfs_init(struct hisi_qm *qm)
{
- struct hpre *hpre = container_of(debug, struct hpre, debug);
- struct hisi_qm *qm = >qm;
+ struct hpre *hpre = container_of(qm, struct hpre, qm);
struct device *dev = >pdev->dev;
char buf[HPRE_DBGFS_VAL_MAX_LEN];
struct debugfs_regset32 *regset;
@@ -623,7 +622,7 @@ static int hpre_cluster_debugfs_init(struct hpre_debug
*debug)
ret = snprintf(buf, HPRE_DBGFS_VAL_MAX_LEN, "cluster%d", i);
if (ret < 0)
return -EINVAL;
- tmp_d = debugfs_create_dir(buf, debug->debug_root);
+ tmp_d = debugfs_create_dir(buf, qm->debug.debug_root);
regset = devm_kzalloc(dev, sizeof(*regset), GFP_KERNEL);
if (!regset)
@@ -634,7 +633,7 @@ static int hpre_cluster_debugfs_init(struct hpre_debug
*debug)
regset->base = qm->io_base + hpre_cluster_offsets[i];
debugfs_create_regset32("regs", 0444, tmp_d, regset);
- ret = hpre_create_debugfs_file(debug, tmp_d, HPRE_CLUSTER_CTRL,
+ ret = hpre_create_debugfs_file(qm, tmp_d, HPRE_CLUSTER_CTRL,
i + HPRE_CLUSTER_CTRL);
if (ret)
return ret;
@@ -643,32 +642,31 @@ static int hpre_cluster_debugfs_init(struct hpre_debug
*debug)
return 0;
}
-static int hpre_ctrl_debug_init(struct hpre_debug *debug)
+static int hpre_ctrl_debug_init(struct hisi_qm *qm)
{
int ret;
- ret = hpre_create_debugfs_file(debug, NULL, HPRE_CURRENT_QM,
+ ret = hpre_create_debugfs_file(qm, NULL, HPRE_CURRENT_QM,
HPRE_CURRENT_QM);
if (ret)
return ret;
- ret = hpre_create_debugfs_file(debug, NULL, HPRE_CLEAR_ENABLE,
+ ret = hpre_create_debugfs_file(qm, NULL, HPRE_CLEAR_ENABLE,
HPRE_CLEAR_ENABLE);
if (ret)
return ret;
- ret = hpre_pf_comm_regs_debugfs_init(debug);
+ ret = hpre_pf_comm_regs_debugfs_init(qm);
if (ret)
return ret;
- return hpre_cluster_debugfs_init(debug);
+ return hpre_cluster_debugfs_init(qm);
}
-static void hpre_dfx_debug_init(struct hpre_debug *debug)
+static void hpre_dfx_debug_init(struct hisi_qm *qm)
{
- struct hpre *hpre = container_of(debug, struct hpre, debug);
+ struct hpre *hpre = container_of(qm, struct hpre, qm);
struct hpre_dfx *dfx = hpre->debug.dfx;
- struct hisi_qm *qm = >qm;
struct dentry *parent;
int i;
@@ -680,30 +678,27 @@ static
[PATCH 1/6] crypto: hisilicon/hpre - Init the value of current_q of debugfs
Initialize current queue number as HPRE_PF_DEF_Q_NUM, or it is zero
and we can't set its value by "current_q_write".
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
Reviewed-by: Hui Tang
---
drivers/crypto/hisilicon/hpre/hpre_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/hisilicon/hpre/hpre_main.c
b/drivers/crypto/hisilicon/hpre/hpre_main.c
index 52d605b..624276b 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_main.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_main.c
@@ -737,6 +737,7 @@ static int hpre_qm_init(struct hisi_qm *qm, struct pci_dev
*pdev)
if (qm->fun_type == QM_HW_PF) {
qm->qp_base = HPRE_PF_DEF_Q_BASE;
qm->qp_num = pf_q_num;
+ qm->debug.curr_qm_qp_num = pf_q_num;
qm->qm_list = _devices;
}
--
2.8.1
[PATCH 6/6] crypto: hisilicon/hpre - disable FLR triggered by hardware
From: Hui Tang
for Hi1620 hardware, we should disable these hardware flr:
1. BME_FLR - bit 7,
2. PM_FLR - bit 11,
3. SRIOV_FLR - bit 12,
Or HPRE may goto D3 state, when we bind and unbind HPRE quickly,
as it does FLR triggered by BME/PM/SRIOV.
Fixes: c8b4b477079d("crypto: hisilicon - add HiSilicon HPRE accelerator")
Signed-off-by: Hui Tang
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/hpre/hpre_main.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/hisilicon/hpre/hpre_main.c
b/drivers/crypto/hisilicon/hpre/hpre_main.c
index 6f7a453..6d8a110 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_main.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_main.c
@@ -82,6 +82,10 @@
#define HPRE_CORE_ECC_2BIT_ERR BIT(1)
#define HPRE_OOO_ECC_2BIT_ERR BIT(5)
+#define HPRE_QM_BME_FLRBIT(7)
+#define HPRE_QM_PM_FLR BIT(11)
+#define HPRE_QM_SRIOV_FLR BIT(12)
+
#define HPRE_VIA_MSI_DSM 1
#define HPRE_SQE_MASK_OFFSET 8
#define HPRE_SQE_MASK_LEN 24
@@ -234,6 +238,21 @@ static int hpre_cfg_by_dsm(struct hisi_qm *qm)
return 0;
}
+/* for Hi1620, we shoul disable FLR triggered by hardware (BME/PM/SRIOV).
+ * Or it may stay in D3 state when we bind and unbind hpre quickly,
+ * as it does FLR triggered by hardware.
+ */
+static void disable_flr_of_bme(struct hisi_qm *qm)
+{
+ u32 val;
+
+ val = readl(HPRE_ADDR(qm, QM_PEH_AXUSER_CFG));
+ val &= ~(HPRE_QM_BME_FLR | HPRE_QM_SRIOV_FLR);
+ val |= HPRE_QM_PM_FLR;
+ writel(val, HPRE_ADDR(qm, QM_PEH_AXUSER_CFG));
+ writel(PEH_AXUSER_CFG_ENABLE, HPRE_ADDR(qm, QM_PEH_AXUSER_CFG_ENABLE));
+}
+
static int hpre_set_user_domain_and_cache(struct hisi_qm *qm)
{
struct device *dev = >pdev->dev;
@@ -245,10 +264,6 @@ static int hpre_set_user_domain_and_cache(struct hisi_qm
*qm)
writel(HPRE_QM_USR_CFG_MASK, HPRE_ADDR(qm, QM_AWUSER_M_CFG_ENABLE));
writel_relaxed(HPRE_QM_AXI_CFG_MASK, HPRE_ADDR(qm, QM_AXI_M_CFG));
- /* disable FLR triggered by BME(bus master enable) */
- writel(PEH_AXUSER_CFG, HPRE_ADDR(qm, QM_PEH_AXUSER_CFG));
- writel(PEH_AXUSER_CFG_ENABLE, HPRE_ADDR(qm, QM_PEH_AXUSER_CFG_ENABLE));
-
/* HPRE need more time, we close this interrupt */
val = readl_relaxed(HPRE_ADDR(qm, HPRE_QM_ABNML_INT_MASK));
val |= BIT(HPRE_TIMEOUT_ABNML_BIT);
@@ -299,6 +314,8 @@ static int hpre_set_user_domain_and_cache(struct hisi_qm
*qm)
if (ret)
dev_err(dev, "acpi_evaluate_dsm err.\n");
+ disable_flr_of_bme(qm);
+
return ret;
}
--
2.8.1
[PATCH 0/6] crypto: hisilicon/hpre bugfix - misc fixes
Bugfix: crypto: hisilicon/hpre - modify the macros, add a switch in sriov_configure, unified debugfs interface, and disable hardware FLR. Hui Tang (2): crypto: hisilicon/hpre - HPRE_OVERTIME_THRHLD can be written by debugfs crypto: hisilicon/hpre - disable FLR triggered by hardware Meng Yu (4): crypto: hisilicon/hpre - Init the value of current_q of debugfs crypto: hisilicon/hpre - Modify the Macro definition and format crypto: hisilicon/hpre - Add a switch in sriov_configure crypto: hisilicon/hpre - update debugfs interface parameters drivers/crypto/hisilicon/hpre/hpre_main.c | 114 -- 1 file changed, 62 insertions(+), 52 deletions(-) -- 2.8.1
[PATCH 3/6] crypto: hisilicon/hpre - Modify the Macro definition and format
1. Bit 1 to bit 5 are NFE, not CE.
2. Macro 'HPRE_VF_NUM' is defined in 'qm.h', so delete it here.
3. Delete multiple blank lines.
4. Adjust format alignment.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
Reviewed-by: Longfang Liu
---
drivers/crypto/hisilicon/hpre/hpre_main.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/crypto/hisilicon/hpre/hpre_main.c
b/drivers/crypto/hisilicon/hpre/hpre_main.c
index be7c20e..1216405 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_main.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_main.c
@@ -12,7 +12,6 @@
#include
#include "hpre.h"
-#define HPRE_VF_NUM63
#define HPRE_QUEUE_NUM_V2 1024
#define HPRE_QM_ABNML_INT_MASK 0x14
#define HPRE_CTRL_CNT_CLR_CE_BIT BIT(0)
@@ -46,9 +45,9 @@
#define HPRE_CORE_IS_SCHD_OFFSET 0x90
#define HPRE_RAS_CE_ENB0x301410
-#define HPRE_HAC_RAS_CE_ENABLE 0x3f
+#define HPRE_HAC_RAS_CE_ENABLE 0x1
#define HPRE_RAS_NFE_ENB 0x301414
-#define HPRE_HAC_RAS_NFE_ENABLE0x3fffc0
+#define HPRE_HAC_RAS_NFE_ENABLE0x3e
#define HPRE_RAS_FE_ENB0x301418
#define HPRE_HAC_RAS_FE_ENABLE 0
@@ -165,7 +164,6 @@ static const struct debugfs_reg32 hpre_com_dfx_regs[] = {
{"INT_STATUS ", HPRE_INT_STATUS},
};
-
static const char *hpre_dfx_files[HPRE_DFX_FILE_NUM] = {
"send_cnt",
"recv_cnt",
@@ -269,7 +267,7 @@ static int hpre_set_user_domain_and_cache(struct hisi_qm
*qm)
writel(HPRE_BD_USR_MASK, HPRE_ADDR(qm, HPRE_BD_AWUSR_CFG));
writel(0x1, HPRE_ADDR(qm, HPRE_RDCHN_INI_CFG));
ret = readl_relaxed_poll_timeout(HPRE_ADDR(qm, HPRE_RDCHN_INI_ST), val,
- val & BIT(0),
+val & BIT(0),
HPRE_REG_RD_INTVRL_US,
HPRE_REG_RD_TMOUT_US);
if (ret) {
@@ -377,7 +375,6 @@ static int hpre_current_qm_write(struct hpre_debugfs_file
*file, u32 val)
u32 num_vfs = qm->vfs_num;
u32 vfq_num, tmp;
-
if (val > num_vfs)
return -EINVAL;
@@ -454,7 +451,7 @@ static int hpre_cluster_inqry_write(struct
hpre_debugfs_file *file, u32 val)
}
static ssize_t hpre_ctrl_debug_read(struct file *filp, char __user *buf,
- size_t count, loff_t *pos)
+ size_t count, loff_t *pos)
{
struct hpre_debugfs_file *file = filp->private_data;
char tbuf[HPRE_DBGFS_VAL_MAX_LEN];
@@ -482,7 +479,7 @@ static ssize_t hpre_ctrl_debug_read(struct file *filp, char
__user *buf,
}
static ssize_t hpre_ctrl_debug_write(struct file *filp, const char __user *buf,
- size_t count, loff_t *pos)
+size_t count, loff_t *pos)
{
struct hpre_debugfs_file *file = filp->private_data;
char tbuf[HPRE_DBGFS_VAL_MAX_LEN];
@@ -916,7 +913,6 @@ static void hpre_remove(struct pci_dev *pdev)
hisi_qm_uninit(qm);
}
-
static const struct pci_error_handlers hpre_err_handler = {
.error_detected = hisi_qm_dev_err_detected,
.slot_reset = hisi_qm_dev_slot_reset,
--
2.8.1
[PATCH 4/6] crypto: hisilicon/hpre - Add a switch in sriov_configure
If CONFIG_PCI_IOV is not enabled, we can not use "sriov_configure".
Fixes: 5ec302a364bf("crypto: hisilicon - add SRIOV support for HPRE")
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
Reviewed-by: Shukun Tan
---
drivers/crypto/hisilicon/hpre/hpre_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/hisilicon/hpre/hpre_main.c
b/drivers/crypto/hisilicon/hpre/hpre_main.c
index 1216405..bfe8a91 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_main.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_main.c
@@ -925,7 +925,8 @@ static struct pci_driver hpre_pci_driver = {
.id_table = hpre_dev_ids,
.probe = hpre_probe,
.remove = hpre_remove,
- .sriov_configure= hisi_qm_sriov_configure,
+ .sriov_configure= IS_ENABLED(CONFIG_PCI_IOV) ?
+ hisi_qm_sriov_configure : NULL,
.err_handler= _err_handler,
.shutdown = hisi_qm_dev_shutdown,
};
--
2.8.1
[PATCH 2/6] crypto: hisilicon/hpre - HPRE_OVERTIME_THRHLD can be written by debugfs
From: Hui Tang
Registers in "hpre_dfx_files" can only be cleaned to zero but
HPRE_OVERTIME_THRHLD, which can be written as any number.
Fixes: 64a6301ebee7("crypto: hisilicon/hpre - add debugfs for ...")
Signed-off-by: Hui Tang
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
Reviewed-by: Zhou Wang
---
drivers/crypto/hisilicon/hpre/hpre_main.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/hisilicon/hpre/hpre_main.c
b/drivers/crypto/hisilicon/hpre/hpre_main.c
index 624276b..be7c20e 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_main.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_main.c
@@ -553,13 +553,15 @@ static int hpre_debugfs_atomic64_get(void *data, u64 *val)
static int hpre_debugfs_atomic64_set(void *data, u64 val)
{
struct hpre_dfx *dfx_item = data;
- struct hpre_dfx *hpre_dfx = dfx_item - HPRE_OVERTIME_THRHLD;
+ struct hpre_dfx *hpre_dfx = NULL;
- if (val)
+ if (dfx_item->type == HPRE_OVERTIME_THRHLD) {
+ hpre_dfx = dfx_item - HPRE_OVERTIME_THRHLD;
+ atomic64_set(_dfx[HPRE_OVER_THRHLD_CNT].value, 0);
+ } else if (val) {
return -EINVAL;
+ }
- if (dfx_item->type == HPRE_OVERTIME_THRHLD)
- atomic64_set(_dfx[HPRE_OVER_THRHLD_CNT].value, 0);
atomic64_set(_item->value, val);
return 0;
--
2.8.1
