Re: [PATCH] staging: slicoss: Fix prefer ether_addr_copy over memcpy
On Tuesday, March 18, 2014 2:04 PM, Joel Pelaez Jorge wrote:
>
> This patch fixes the following checkpatch.pl issues caused by the new
> function: ether_addr_copy
>
> Signed-off-by: Joel Pelaez Jorge
> ---
> drivers/staging/slicoss/slicoss.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/slicoss/slicoss.c
> b/drivers/staging/slicoss/slicoss.c
> index 12aafe3..0e0e374 100644
> --- a/drivers/staging/slicoss/slicoss.c
> +++ b/drivers/staging/slicoss/slicoss.c
> @@ -581,15 +581,15 @@ static void slic_adapter_set_hwaddr(struct adapter
> *adapter)
> struct sliccard *card = adapter->card;
>
> if ((adapter->card) && (card->config_set)) {
> - memcpy(adapter->macaddr,
> -card->config.MacInfo[adapter->functionnumber].macaddrA,
> -sizeof(struct slic_config_mac));
> + ether_addr_copy(adapter->macaddr,
> + card->config.MacInfo[adapter->functionnumber]
> + .macaddrA);
As declared in ./include/linux/etherdevice.h,
Copied size should be a six-byte.
static inline void ether_addr_copy(u8 *dst, const u8 *src)
{
#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
*(u32 *)dst = *(const u32 *)src;
*(u16 *)(dst + 4) = *(const u16 *)(src + 4);
#else
u16 *a = (u16 *)dst;
const u16 *b = (const u16 *)src;
a[0] = b[0];
a[1] = b[1];
a[2] = b[2];
#endif
}
In this case, sizeof(struct slic_config_mac) will be 6 byte,
as below. So, it looks good.
./drivers/staging/slicoss/slichw.h
struct slic_config_mac {
u8 macaddrA[6];
};
> if (is_zero_ether_addr(adapter->currmacaddr))
> - memcpy(adapter->currmacaddr, adapter->macaddr,
> -ETH_ALEN);
> + ether_addr_copy(adapter->currmacaddr,
> + adapter->macaddr);
> if (adapter->netdev)
> - memcpy(adapter->netdev->dev_addr, adapter->currmacaddr,
> -ETH_ALEN);
> + ether_addr_copy(adapter->netdev->dev_addr,
> + adapter->currmacaddr);
> }
> }
ETH_ALEN is defined as 6. It looks good, too.
./include/uapi/linux/if_ether.h
#define ETH_ALEN 6
>
> @@ -810,8 +810,8 @@ static int slic_mac_set_address(struct net_device
> *dev, void *ptr)
> if (!is_valid_ether_addr(addr->sa_data))
> return -EINVAL;
>
> - memcpy(dev->dev_addr, addr->sa_data, dev->addr_len);
> - memcpy(adapter->currmacaddr, addr->sa_data, dev->addr_len);
> + ether_addr_copy(dev->dev_addr, addr->sa_data);
> + ether_addr_copy(adapter->currmacaddr, addr->sa_data);
By the way, I am wondering if 'dev->addr_len' is 6 bytes.
Is there anyone who can confirm it?
If nobody can confirm 'dev->addr_len' is 6 bytes, it should
not be changed to 'ether_addr_copy()'.
Best regards,
Jingoo Han
>
> slic_config_set(adapter, true);
> return 0;
> @@ -2313,7 +2313,7 @@ static int slic_mcast_add_list(struct adapter
> *adapter, char *address)
> if (mcaddr == NULL)
> return 1;
>
> - memcpy(mcaddr->address, address, ETH_ALEN);
> + ether_addr_copy(mcaddr->address, address);
>
> mcaddr->next = adapter->mcastaddrs;
> adapter->mcastaddrs = mcaddr;
> --
> 1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] drm/exynos: Fix (more) freeing issues in exynos_drm_drv.c
Inki Dae wrote: > > Applied. > > Thanks, > Inki Dae > > 2014-03-17 12:28 GMT+09:00 Daniel Kurtz : > > The following commit [0] fixed a use-after-free, but left the subdrv > open > > in the error path. > > > > [0] commit 6ca605f7c70895a35737435f17ae9cc5e36f1466 > > drm/exynos: Fix freeing issues in exynos_drm_drv.c > > > > Change-Id: I452e944bf090fb11434d9e34213c890c41c15d73 This should be removed when Inki apply this. Thanks, Kukjin > > Signed-off-by: Daniel Kurtz > > --- > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 10 +++--- > > 1 file changed, 7 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] intel_pstate: Set core to min P state during core offline
On Sat, Mar 15, 2014 at 2:33 AM, wrote:
> From: Dirk Brandewie
>
> Change to use ->stop() callback to do clean up during CPU
> hotplug. The requested P state for an offline core will be used by the
> hardware coordination function to select the package P state. If the
> core is under load when it is offlined it will fix the package P state
> floor to the requested P state of offline core.
>
> Reported-by: Patrick Marlier
> Signed-off-by: Dirk Brandewie
> ---
> drivers/cpufreq/intel_pstate.c | 20 +---
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index 2cd36b9..e9092fd 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -447,7 +447,7 @@ static void core_set_pstate(struct cpudata *cpudata, int
> pstate)
> if (limits.no_turbo)
> val |= (u64)1 << 32;
>
> - wrmsrl(MSR_IA32_PERF_CTL, val);
> + wrmsrl_on_cpu(cpudata->cpu, MSR_IA32_PERF_CTL, val);
> }
>
> static struct cpu_defaults core_params = {
> @@ -773,16 +773,22 @@ static int intel_pstate_verify_policy(struct
> cpufreq_policy *policy)
> return 0;
> }
>
> -static int intel_pstate_cpu_exit(struct cpufreq_policy *policy)
> +static int intel_pstate_cpu_stop(struct cpufreq_policy *policy)
> {
> - int cpu = policy->cpu;
> + int cpu_num = policy->cpu;
> + struct cpudata *cpu = all_cpu_data[cpu_num];
> +
> + pr_info("intel_pstate CPU %d exiting\n", cpu_num);
> +
> + del_timer(_cpu_data[cpu_num]->timer);
> + intel_pstate_set_pstate(cpu, cpu->pstate.min_pstate);
> + kfree(all_cpu_data[cpu_num]);
> + all_cpu_data[cpu_num] = NULL;
>
> - del_timer(_cpu_data[cpu]->timer);
> - kfree(all_cpu_data[cpu]);
> - all_cpu_data[cpu] = NULL;
> return 0;
> }
>
> +
> static int intel_pstate_cpu_init(struct cpufreq_policy *policy)
> {
> struct cpudata *cpu;
> @@ -818,7 +824,7 @@ static struct cpufreq_driver intel_pstate_driver = {
> .setpolicy = intel_pstate_set_policy,
> .get= intel_pstate_get,
> .init = intel_pstate_cpu_init,
> - .exit = intel_pstate_cpu_exit,
> + .stop = intel_pstate_cpu_stop,
Probably, keep exit as is and only change P-state in stop(). So that
allocation of resources happen in init() and they are freed in exit()?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] cpufreq: Add exit_prepare callback to cpufreq_driver interface
On Sat, Mar 15, 2014 at 7:34 AM, Rafael J. Wysocki wrote:
> On Friday, March 14, 2014 02:03:56 PM dirk.brande...@gmail.com wrote:
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -1338,6 +1338,9 @@ static int __cpufreq_remove_dev_prepare(struct device
>> *dev,
>> }
>> }
>>
>> + if (cpufreq_driver->stop)
>
> What about doing
>
> + if (cpufreq_driver->setpolicy && cpufreq_driver->stop)
>
> here instead? That would make it clear where the new callback belongs.
This is called after stopping governor and so might be useful for ->target()
drivers. So, wouldn't be a bad option if we keep it available for all..
@Dirk: I thought about the solution I mentioned in another mail. And it looks
like I will end up getting a similar solution. So, we will go with
your solution.
Just few changes for your solution..
You need to call ->stop() only for the last CPU of every policy and not for
every CPU, so you need something like this:
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 19d25a8..78d41c0 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1371,6 +1371,8 @@ static int __cpufreq_remove_dev_prepare(struct
device *dev,
__func__, new_cpu, cpu);
}
}
+ } else if (cpufreq_driver->stop) {
+ cpufreq_driver->stop(policy);
}
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [RESEND] frv: remove deprecated IRQF_DISABLED
This patch removes the IRQF_DISABLED flag from FRV architecture
code. It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/frv/kernel/irq-mb93091.c | 8
arch/frv/kernel/irq-mb93093.c | 1 -
arch/frv/kernel/irq-mb93493.c | 4 ++--
arch/frv/kernel/time.c| 1 -
4 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/frv/kernel/irq-mb93091.c b/arch/frv/kernel/irq-mb93091.c
index 2cc327a1ca44..091b2839be90 100644
--- a/arch/frv/kernel/irq-mb93091.c
+++ b/arch/frv/kernel/irq-mb93091.c
@@ -107,25 +107,25 @@ static irqreturn_t fpga_interrupt(int irq, void *_mask)
static struct irqaction fpga_irq[4] = {
[0] = {
.handler= fpga_interrupt,
- .flags = IRQF_DISABLED | IRQF_SHARED,
+ .flags = IRQF_SHARED,
.name = "fpga.0",
.dev_id = (void *) 0x0028UL,
},
[1] = {
.handler= fpga_interrupt,
- .flags = IRQF_DISABLED | IRQF_SHARED,
+ .flags = IRQF_SHARED,
.name = "fpga.1",
.dev_id = (void *) 0x0050UL,
},
[2] = {
.handler= fpga_interrupt,
- .flags = IRQF_DISABLED | IRQF_SHARED,
+ .flags = IRQF_SHARED,
.name = "fpga.2",
.dev_id = (void *) 0x1c00UL,
},
[3] = {
.handler= fpga_interrupt,
- .flags = IRQF_DISABLED | IRQF_SHARED,
+ .flags = IRQF_SHARED,
.name = "fpga.3",
.dev_id = (void *) 0x6386UL,
}
diff --git a/arch/frv/kernel/irq-mb93093.c b/arch/frv/kernel/irq-mb93093.c
index 95e4eb4f1f38..1f3015cf80f5 100644
--- a/arch/frv/kernel/irq-mb93093.c
+++ b/arch/frv/kernel/irq-mb93093.c
@@ -105,7 +105,6 @@ static irqreturn_t fpga_interrupt(int irq, void *_mask)
static struct irqaction fpga_irq[1] = {
[0] = {
.handler= fpga_interrupt,
- .flags = IRQF_DISABLED,
.name = "fpga.0",
.dev_id = (void *) 0x0700UL,
}
diff --git a/arch/frv/kernel/irq-mb93493.c b/arch/frv/kernel/irq-mb93493.c
index ba648da0932d..8ca5aa4ff595 100644
--- a/arch/frv/kernel/irq-mb93493.c
+++ b/arch/frv/kernel/irq-mb93493.c
@@ -118,13 +118,13 @@ static irqreturn_t mb93493_interrupt(int irq, void
*_piqsr)
static struct irqaction mb93493_irq[2] = {
[0] = {
.handler= mb93493_interrupt,
- .flags = IRQF_DISABLED | IRQF_SHARED,
+ .flags = IRQF_SHARED,
.name = "mb93493.0",
.dev_id = (void *) __addr_MB93493_IQSR(0),
},
[1] = {
.handler= mb93493_interrupt,
- .flags = IRQF_DISABLED | IRQF_SHARED,
+ .flags = IRQF_SHARED,
.name = "mb93493.1",
.dev_id = (void *) __addr_MB93493_IQSR(1),
}
diff --git a/arch/frv/kernel/time.c b/arch/frv/kernel/time.c
index b457de496b70..332e00bf9d06 100644
--- a/arch/frv/kernel/time.c
+++ b/arch/frv/kernel/time.c
@@ -44,7 +44,6 @@ static irqreturn_t timer_interrupt(int irq, void *dummy);
static struct irqaction timer_irq = {
.handler = timer_interrupt,
- .flags = IRQF_DISABLED,
.name = "timer",
};
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RESEND] [SCSI] misc drivers: remove deprecated IRQF_DISABLED
Hi, On 03/05/2014 06:45 AM, Michael Opdenacker wrote: > This patch removes the use of the IRQF_DISABLED flag > in several drivers in drivers/scsi/ > > It's a NOOP since 2.6.35 and it will be removed one day. > > Signed-off-by: Michael Opdenacker > --- > drivers/scsi/dtc.c| 2 +- > drivers/scsi/esas2r/esas2r_init.c | 2 +- > drivers/scsi/g_NCR5380.c | 2 +- > drivers/scsi/gdth.c | 6 +++--- > drivers/scsi/in2000.c | 2 +- > drivers/scsi/initio.c | 2 +- > drivers/scsi/pas16.c | 2 +- > drivers/scsi/pm8001/pm8001_init.c | 2 -- > drivers/scsi/t128.c | 2 +- > 9 files changed, 10 insertions(+), 12 deletions(-) As the maintainers don't seem to have time for this, I will trying to get my IRQF_DISABLED patches merged through Andrew Morton. Michael. -- Michael Opdenacker, CEO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com +33 484 258 098 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] SPI: Add driver for Cadence SPI controller
Hi Mark,
> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Monday, March 17, 2014 11:45 PM
> To: Josh Cartwright
> Cc: Harini Katakam; robh...@kernel.org; pawel.m...@arm.com;
> mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk;
> ga...@codeaurora.org; r...@landley.net; grant.lik...@linaro.org;
> devicet...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-...@vger.kernel.org; Michal Simek
> Subject: Re: [PATCH] SPI: Add driver for Cadence SPI controller
>
> On Mon, Mar 17, 2014 at 12:59:11PM -0500, Josh Cartwright wrote:
> > On Mon, Mar 17, 2014 at 05:30:17PM +, Mark Brown wrote:
> > > On Mon, Mar 17, 2014 at 05:35:36PM +0530, Harini Katakam wrote:
>
> > > > +static int __maybe_unused cdns_spi_suspend(struct device *dev) {
>
> > > This needs to call spi_master_suspend() as well (and similarly on
> > > resume).
>
> > I'm not that familiar with the SPI core, but this seems like an
> > inversion. Is there a reason why the SPI master class doesn't
> > implement
> > suspend/resume() callbacks which handle stopping/starting the queue
> > automatically for all masters?
>
> This is for users of an optional feature of the infrastructure. We probably
> should just call it anyway since it does have checks for the feature being
> used (but given all the open coding around this stuff I'd need to verify that
> the class callbacks would reliably get called).
>
> In any case that's not happening now and the driver as it stands is buggy
> since it's trampling all over the hardware without syncing with anything that
> isn't ongoing.
In case of a suspend, we are stopping an ongoing transfer and disabling the
interface.
In case I add clock disable and anything else to unprepared too, it will be a
cleaner
exit but it will still stop the transfer right? What do you suggest?
Should we wait for transfer to complete or a timeout to occur?
Regards,
Harini
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] SPI: Add driver for Cadence SPI controller
Hi Mark,
> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Monday, March 17, 2014 11:00 PM
> To: Harini Katakam
> Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; r...@landley.net;
> grant.lik...@linaro.org; devicet...@vger.kernel.org; linux-
> d...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> s...@vger.kernel.org; Michal Simek
> Subject: Re: [PATCH] SPI: Add driver for Cadence SPI controller
>
> On Mon, Mar 17, 2014 at 05:35:36PM +0530, Harini Katakam wrote:
>
> > + bits_per_word = transfer ?
> > + transfer->bits_per_word : spi->bits_per_word;
>
> This would be a lot more legible without the ternery operator.
>
> > + if (bits_per_word != 8) {
> > + dev_err(>dev, "%s, unsupported bits per word %x\n",
> > + __func__, spi->bits_per_word);
> > + return -EINVAL;
> > + }
>
> The core will check this for you.
I dint find that the core does this.
>
> > +static int cdns_spi_setup(struct spi_device *spi) {
> > + if (!spi->max_speed_hz)
> > + return -EINVAL;
> > +
> > + if (!spi->bits_per_word)
> > + spi->bits_per_word = 8;
>
> The core does this for you.
I understand that the core does this.
>
> > + return cdns_spi_setup_transfer(spi, NULL); }
>
> It's not clear to me why this has been split into a separate function and the
> function will write to the hardware which you're not allowed to do in
> setup() if it might affect an ongoing transfer.
Are you saying that there's a chance cdns_spi_setup() will be called when
there's an ongoing transfer?
In that case I have to remove the cdns_setup_transfer() call from here but then
there's nothing left to do in setup.
The function was split into two because cdns_spi_setup_transfer() is called
internally
by transfer_one_message() everytime.
Is it always possible that the spi_transfer paramters will remain the same;
In that case this call is probably not necessary in transfer_one_message.
>
> > + intr_status = cdns_spi_read(xspi->regs + CDNS_SPI_ISR_OFFSET);
> > + cdns_spi_write(xspi->regs + CDNS_SPI_ISR_OFFSET, intr_status);
> > +
> > + if (intr_status & CDNS_SPI_IXR_MODF_MASK) {
> > + /* Indicate that transfer is completed, the SPI subsystem will
> > +* identify the error as the remaining bytes to be
> > +* transferred is non-zero
> > +*/
> > + cdns_spi_write(xspi->regs + CDNS_SPI_IDR_OFFSET,
> > + CDNS_SPI_IXR_DEFAULT_MASK);
> > + complete(>done);
> > + } else if (intr_status & CDNS_SPI_IXR_TXOW_MASK) {
>
> What happens if both interrupts are flagged at the same time?
The MODF is an error interrupt and so if TXOW is raised along with it,
TXOW will be ignored (it will be cleared but no data is read).
Completion is indicated and since the remaining bytes is non-zero,
The transfer function will understand that it is an error.
>
> > + if (xspi->remaining_bytes) {
> > + /* There is more data to send */
> > + cdns_spi_fill_tx_fifo(xspi);
> > + } else {
> > + /* Transfer is completed */
> > + cdns_spi_write(xspi->regs + CDNS_SPI_IDR_OFFSET,
> > + CDNS_SPI_IXR_DEFAULT_MASK);
> > + complete(>done);
> > + }
> > + }
>
> I see from further up the file that there are error interrupt states which
> might be flagged but these are just being ignored.
I'm not sure I understand what you are referring to -
The only interrupts enabled (See CNDS_IXR_DEFAULT_MASK) are TXOW and MODF.
>
> > +
> > + return IRQ_HANDLED;
>
> This should only be returned if an interrupt was actually handled - if the
> line
> is shared in some system this will break.
In this case both possible interrupt conditions are handled.
>
> > + cdns_spi_write(xspi->regs + CDNS_SPI_IER_OFFSET,
> > + CDNS_SPI_IXR_DEFAULT_MASK);
> > +
> > + ret = wait_for_completion_interruptible_timeout(>done,
> > + CDNS_SPI_TIMEOUT);
> > + if (ret < 1) {
>
> If you return a positive value from transfer_one() the core will wait for you.
>
I don't understand. Here, if the ret from
wait_for_completion_interruptible_timeout is
positive, then this function (spi_start_transfer) will return (transfer->len) -
(xspi->remaining_bytes)
to cdns_transfer_one_message(the calling funtion). Which will just use this
return as
information on how many bytes were transferred (see variable length).
cdns_transfer_one_messag() only returns 0 or error value (-ve) (see variable
status).
It doesn't return positive value to core.
> > +static int cdns_prepare_transfer_hardware(struct spi_master *master)
> > +{
> > + struct cdns_spi *xspi = spi_master_get_devdata(master);
> > +
> > + if
Re: [PATCH 0/2] Add exit_prepare callback to the cpufreq_driver interface.
On Sat, Mar 15, 2014 at 7:29 AM, Rafael J. Wysocki wrote: > I honestly don't think that ->target drivers will ever do anything like it, > because they need the governor to "exit" before. So we are talking about the > only two ->setpolicy drivers in the tree here. I don't have a example platform which would need it but as I can see there are platforms which want to do this when CPUs goes down from disable_nonboot_cpus(), I would be in favor to keep this option available for them as well.. They might want to do this when last CPU of a policy goes down, they might be able to save some power over there. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Add exit_prepare callback to the cpufreq_driver interface.
Hi, It was a long weekend in India due to some holidays and so couldn't reply. On Fri, Mar 14, 2014 at 11:59 PM, Dirk Brandewie wrote: > On 03/14/2014 10:07 AM, Viresh Kumar wrote: > Suspend and hotplug are two very different things and if we start > crossing those wires bad things are going to happen IMHO. > > In "normal" operation using the suspend path to do this work could > work in principal but doesn't handle the case where the user does >echo 0 | sudo tee /sys/devices/system/cpu/cpuX/online > > Trying force hotplug and suspend into a common mechanism would > lead to a bunch of special case code or a significant rework of the > core code IMHO. What you said is correct, we shouldn't do it. But what I am asking for is a bit different. The stuff we are doing in core on system suspend isn't actually related to suspend but only CPU online/offline. There are platforms which want to set CPUs to a particular frequency before they are taken out by disable_nonboot_cpus. And then there are platforms which want to do similar thing when CPUs are taken down with help of sysfs files. But there is a common baseline there: Set CPUs to a particular P-state before they are taken down. And so I wanted to keep a common solution for both these requirements. > This is guaranteed by the hardware. Each core has its own MSR for P state > request. Any coordination that is required between cores to select the > package P state is handled by the hardware. I see.. Let me send some patches which I have in my mind and then we can decide which set looks more reasonable :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: slicoss: Fix prefer ether_addr_copy over memcpy
This patch fixes the following checkpatch.pl issues caused by the new
function: ether_addr_copy
Signed-off-by: Joel Pelaez Jorge
---
drivers/staging/slicoss/slicoss.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/slicoss/slicoss.c
b/drivers/staging/slicoss/slicoss.c
index 12aafe3..0e0e374 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -581,15 +581,15 @@ static void slic_adapter_set_hwaddr(struct adapter
*adapter)
struct sliccard *card = adapter->card;
if ((adapter->card) && (card->config_set)) {
- memcpy(adapter->macaddr,
- card->config.MacInfo[adapter->functionnumber].macaddrA,
- sizeof(struct slic_config_mac));
+ ether_addr_copy(adapter->macaddr,
+ card->config.MacInfo[adapter->functionnumber]
+ .macaddrA);
if (is_zero_ether_addr(adapter->currmacaddr))
- memcpy(adapter->currmacaddr, adapter->macaddr,
- ETH_ALEN);
+ ether_addr_copy(adapter->currmacaddr,
+ adapter->macaddr);
if (adapter->netdev)
- memcpy(adapter->netdev->dev_addr, adapter->currmacaddr,
- ETH_ALEN);
+ ether_addr_copy(adapter->netdev->dev_addr,
+ adapter->currmacaddr);
}
}
@@ -810,8 +810,8 @@ static int slic_mac_set_address(struct net_device
*dev, void *ptr)
if (!is_valid_ether_addr(addr->sa_data))
return -EINVAL;
- memcpy(dev->dev_addr, addr->sa_data, dev->addr_len);
- memcpy(adapter->currmacaddr, addr->sa_data, dev->addr_len);
+ ether_addr_copy(dev->dev_addr, addr->sa_data);
+ ether_addr_copy(adapter->currmacaddr, addr->sa_data);
slic_config_set(adapter, true);
return 0;
@@ -2313,7 +2313,7 @@ static int slic_mcast_add_list(struct adapter
*adapter, char *address)
if (mcaddr == NULL)
return 1;
- memcpy(mcaddr->address, address, ETH_ALEN);
+ ether_addr_copy(mcaddr->address, address);
mcaddr->next = adapter->mcastaddrs;
adapter->mcastaddrs = mcaddr;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm/exynos: Fix (more) freeing issues in exynos_drm_drv.c
Applied.
Thanks,
Inki Dae
2014-03-17 12:28 GMT+09:00 Daniel Kurtz :
> The following commit [0] fixed a use-after-free, but left the subdrv open
> in the error path.
>
> [0] commit 6ca605f7c70895a35737435f17ae9cc5e36f1466
> drm/exynos: Fix freeing issues in exynos_drm_drv.c
>
> Change-Id: I452e944bf090fb11434d9e34213c890c41c15d73
> Signed-off-by: Daniel Kurtz
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 215131a..c204b4e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -172,20 +172,24 @@ static int exynos_drm_open(struct drm_device *dev,
> struct drm_file *file)
>
> ret = exynos_drm_subdrv_open(dev, file);
> if (ret)
> - goto out;
> + goto err_file_priv_free;
>
> anon_filp = anon_inode_getfile("exynos_gem", _drm_gem_fops,
> NULL, 0);
> if (IS_ERR(anon_filp)) {
> ret = PTR_ERR(anon_filp);
> - goto out;
> + goto err_subdrv_close;
> }
>
> anon_filp->f_mode = FMODE_READ | FMODE_WRITE;
> file_priv->anon_filp = anon_filp;
>
> return ret;
> -out:
> +
> +err_subdrv_close:
> + exynos_drm_subdrv_close(dev, file);
> +
> +err_file_priv_free:
> kfree(file_priv);
> file->driver_priv = NULL;
> return ret;
> --
> 1.9.0.279.gdc9e3eb
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/9] perf tools: Count periods of filtered entries separately
On Tue, Mar 18, 2014 at 1:19 PM, Namhyung Kim wrote: > It's because thread__find_addr_map() clears al->filtered, so filtering > with -d option won't work. Maybe we can move initialization of the > al->filtered upto this function. Oh, I meant the -c/--comms option actually :) Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux kernel 3.4.83 cross reference is added into www.xrefs.info
hi, linux kernel 3.4.83 cross reference is added into www.xrefs.info. check it out... Thx. xrefs.info admin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/9] perf tools: Count periods of filtered entries separately
On Tue, Mar 18, 2014 at 5:08 AM, Arnaldo Carvalho de Melo
wrote:
> Em Mon, Mar 10, 2014 at 04:43:53PM +0900, Namhyung Kim escreveu:
>> @@ -749,9 +750,6 @@ int perf_event__preprocess_sample(const union perf_event
>> *event,
>> if (thread == NULL)
>> return -1;
>>
>> - if (thread__is_filtered(thread))
>> - goto out_filtered;
>> -
>
> What was the intent of moving this test from here...
>
>> dump_printf(" ... thread: %s:%d\n", thread__comm_str(thread),
>> thread->tid);
>> /*
>>* Have we already created the kernel maps for this machine?
>> @@ -766,6 +764,10 @@ int perf_event__preprocess_sample(const union
>> perf_event *event,
>>
>> thread__find_addr_map(thread, machine, cpumode, MAP__FUNCTION,
>> sample->ip, al);
>> +
>> + if (thread__is_filtered(thread))
>> + al->filtered |= (1 << HIST_FILTER__THREAD);
>> +
>
> ... to here? At first I thought it was because thread__is_filtered()
> would check something that thread__find_addr_map() was doing, but no,
> its invariant, we can do it here or at the original site, so I'm keeping
> it there, ok?
It's because thread__find_addr_map() clears al->filtered, so filtering
with -d option won't work. Maybe we can move initialization of the
al->filtered upto this function.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the audit tree with the mips tree
Hi Eric,
Today's linux-next merge of the audit tree got conflicts in
arch/mips/include/asm/syscall.h and arch/mips/kernel/ptrace.c between
commits cdda64d4d01f ("MIPS: asm: syscall: Define syscall_get_arch"),
d74c2862 ("MIPS: ptrace: Move away from secure_computing_strict") and
f5179287b016 ("MIPS: Fix randconfig build error") from the mips tree and
commits 74d0bf770dd6 ("syscall_get_arch: remove useless function
arguments") and e8d1226a197d ("audit: use uapi/linux/audit.h for
AUDIT_ARCH declarations") from the audit tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/mips/include/asm/syscall.h
index 6c488c85d791,fc556d8052c9..
--- a/arch/mips/include/asm/syscall.h
+++ b/arch/mips/include/asm/syscall.h
@@@ -13,8 -13,7 +13,8 @@@
#ifndef __ASM_MIPS_SYSCALL_H
#define __ASM_MIPS_SYSCALL_H
+#include
- #include
+ #include
#include
#include
#include
@@@ -132,8 -105,7 +131,8 @@@ static inline int syscall_get_arch(void
{
int arch = EM_MIPS;
#ifdef CONFIG_64BIT
- if (!test_tsk_thread_flag(task, TIF_32BIT_REGS))
- arch |= __AUDIT_ARCH_64BIT;
++ if (!test_tsk_thread_flag(current, TIF_32BIT_REGS))
+ arch |= __AUDIT_ARCH_64BIT;
#endif
#if defined(__LITTLE_ENDIAN)
arch |= __AUDIT_ARCH_LE;
diff --cc arch/mips/kernel/ptrace.c
index 4137a49eae26,65ba622baf3e..
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@@ -706,11 -671,10 +706,11 @@@ asmlinkage long syscall_trace_enter(str
if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
trace_sys_enter(regs, regs->regs[2]);
- audit_syscall_entry(syscall_get_arch(current, regs),
+ audit_syscall_entry(syscall_get_arch(),
- regs->regs[2],
+ syscall,
regs->regs[4], regs->regs[5],
regs->regs[6], regs->regs[7]);
+ return syscall;
}
/*
pgpA3CKpndUZl.pgp
Description: PGP signature
Re: [PATCH] sched: Initialize rq->age_stamp on processor start
CC maintainer improves patch aerodynamics.
On Mon, 2014-03-17 at 19:05 -0500, miny...@acm.org wrote:
> From: Corey Minyard
>
> If the sched_clock time starts at a large value, the kernel will spin
> in sched_avg_update for a long time while rq->age_stamp catches up
> with rq->clock.
>
> The comment in kernel/sched/clock.c says that there is no strict promise
> that it starts at zero. So initialize rq->age_stamp when a cpu starts up
> to avoid this.
>
> I was seeing long delays on a simulator that didn't start the clock at
> zero. This might also be an issue on reboots on processors that don't
> re-initialize the timer to zero on reset, and when using kexec.
>
> Signed-off-by: Corey Minyard
> ---
> kernel/sched/core.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index b46131e..5be3d4a 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5037,11 +5037,20 @@ static struct notifier_block migration_notifier = {
> .priority = CPU_PRI_MIGRATION,
> };
>
> +static void __cpuinit set_cpu_rq_start_time(void)
> +{
> + int cpu = smp_processor_id();
> + struct rq *rq = cpu_rq(cpu);
> + rq->age_stamp = sched_clock_cpu(cpu);
> +}
rq->age_stamp must lag rq->clock. See scale_rt_power(), and what
happens when it munches magic timewarp mushrooms.
> +
> static int sched_cpu_active(struct notifier_block *nfb,
> unsigned long action, void *hcpu)
> {
> switch (action & ~CPU_TASKS_FROZEN) {
> case CPU_STARTING:
> + set_cpu_rq_start_time();
> + /* fall through */
> case CPU_DOWN_FAILED:
> set_cpu_active((long)hcpu, true);
> return NOTIFY_OK;
> @@ -6922,6 +6931,7 @@ void __init sched_init(void)
> init_sched_fair_class();
>
> scheduler_running = 1;
> + set_cpu_rq_start_time();
> }
>
> #ifdef CONFIG_DEBUG_ATOMIC_SLEEP
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] net: cdc_ncm: respect operator preferred MTU reported by MBIM
On Mon, Mar 17, 2014 at 6:41 PM, David Miller wrote: > From: Ben Chan > Date: Mon, 17 Mar 2014 17:46:27 -0700 > >> Thanks again for the review and tip. I've submitted patch v2 to >> address the le16_to_cpu conversion. > > When you update a patch from a series, you should repost the entire > patch set, rather than just the patch which changes. > > This avoids any and all ambiguity of which patches go with which > others. Thanks for pointing that out. I've submitted the whole patch set as v3 (bumped the revision to avoid confusion). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/2] USB: cdc: add MBIM extended functional descriptor structure
This patch adds the MBIM extended functional descriptor structure
defined in "Universal Serial Bus Communications Class Subclass
Specification for Mobile Broadband Interface Model, Revision 1.0,
Errata-1" published by USB-IF.
Signed-off-by: Ben Chan
---
No changes from patch v1.
include/uapi/linux/usb/cdc.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/uapi/linux/usb/cdc.h b/include/uapi/linux/usb/cdc.h
index f35aa0a..b6a9cdd 100644
--- a/include/uapi/linux/usb/cdc.h
+++ b/include/uapi/linux/usb/cdc.h
@@ -56,6 +56,7 @@
#define USB_CDC_OBEX_TYPE 0x15
#define USB_CDC_NCM_TYPE 0x1a
#define USB_CDC_MBIM_TYPE 0x1b
+#define USB_CDC_MBIM_EXTENDED_TYPE 0x1c
/* "Header Functional Descriptor" from CDC spec 5.2.3.1 */
struct usb_cdc_header_desc {
@@ -205,6 +206,17 @@ struct usb_cdc_mbim_desc {
__u8bmNetworkCapabilities;
} __attribute__ ((packed));
+/* "MBIM Extended Functional Descriptor" from CDC MBIM spec 1.0 errata-1 */
+struct usb_cdc_mbim_extended_desc {
+ __u8bLength;
+ __u8bDescriptorType;
+ __u8bDescriptorSubType;
+
+ __le16 bcdMBIMExtendedVersion;
+ __u8bMaxOutstandingCommandMessages;
+ __le16 wMTU;
+} __attribute__ ((packed));
+
/*-*/
/*
--
1.9.0.279.gdc9e3eb
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/2] net: cdc_ncm: respect operator preferred MTU reported by MBIM
According to "Universal Serial Bus Communications Class Subclass
Specification for Mobile Broadband Interface Model, Revision 1.0,
Errata-1" published by USB-IF, the wMTU field of the MBIM extended
functional descriptor indicates the operator preferred MTU for IP data
streams.
This patch modifies cdc_ncm_setup to ensure that the MTU value set on
the usbnet device does not exceed the operator preferred MTU indicated
by wMTU if the MBIM device exposes a MBIM extended functional
descriptor.
Signed-off-by: Ben Chan
---
Patch v3 (which is same as v2) adds the le16_to_cpu conversion on
ctx->mbim_extended_desc->wMTU as pointed out and suggested by
'Bjørn Mork '.
drivers/net/usb/cdc_ncm.c | 17 +
include/linux/usb/cdc_ncm.h | 1 +
2 files changed, 18 insertions(+)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index dbff290..e8711a8 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -74,6 +74,7 @@ static int cdc_ncm_setup(struct usbnet *dev)
u8 iface_no;
int err;
int eth_hlen;
+ u16 mbim_mtu;
u16 ntb_fmt_supported;
__le16 max_datagram_size;
@@ -261,6 +262,14 @@ out:
/* set MTU to max supported by the device if necessary */
if (dev->net->mtu > ctx->max_datagram_size - eth_hlen)
dev->net->mtu = ctx->max_datagram_size - eth_hlen;
+
+ /* do not exceed operater preferred MTU */
+ if (ctx->mbim_extended_desc) {
+ mbim_mtu = le16_to_cpu(ctx->mbim_extended_desc->wMTU);
+ if (mbim_mtu != 0 && mbim_mtu < dev->net->mtu)
+ dev->net->mtu = mbim_mtu;
+ }
+
return 0;
}
@@ -399,6 +408,14 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct
usb_interface *intf, u8 data_
ctx->mbim_desc = (const struct usb_cdc_mbim_desc *)buf;
break;
+ case USB_CDC_MBIM_EXTENDED_TYPE:
+ if (buf[0] < sizeof(*(ctx->mbim_extended_desc)))
+ break;
+
+ ctx->mbim_extended_desc =
+ (const struct usb_cdc_mbim_extended_desc *)buf;
+ break;
+
default:
break;
}
diff --git a/include/linux/usb/cdc_ncm.h b/include/linux/usb/cdc_ncm.h
index c3fa807..bdf05fb 100644
--- a/include/linux/usb/cdc_ncm.h
+++ b/include/linux/usb/cdc_ncm.h
@@ -93,6 +93,7 @@ struct cdc_ncm_ctx {
const struct usb_cdc_ncm_desc *func_desc;
const struct usb_cdc_mbim_desc *mbim_desc;
+ const struct usb_cdc_mbim_extended_desc *mbim_extended_desc;
const struct usb_cdc_ether_desc *ether_desc;
struct usb_interface *control;
--
1.9.0.279.gdc9e3eb
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET cgroup/for-3.15] cgroup: prepare for the default unified hierarchy
On 2014/3/14 3:50, Tejun Heo wrote:
> Hello,
>
> The planned unified hierarchy is just around the corner. We're gonna
> repurpose the dummy hierarchy to serve as the default unified
> hierarchy. Controllers which aren't attached to other hierarchies are
> already automatically bound to the dummy hierarchy; however, the dummy
> hierarchy is minimally initialized during boot and can't currently act
> as a full hierarchy.
>
> This patchset gradually turns the dummy hierarchy into fully
> functional default one and makes it mountable via selecting
> sane_behavior without any subsystems specified. While this patchset
> does make the default hierarchy mountable, the unified hierarchy
> functionality isn't implemented yet and cgroup creation in the default
> hierarchy is rejected for now.
>
> This lays down all the boilerplate work for the unified hierarchy.
> The next patchset will implement the actual unified functionality.
>
> This patchset contains the following eleven patches.
>
> 0001-cgroup-cgroup-subsys-should-be-cleared-after-the-css.patch
> 0002-cgroup-relocate-setting-of-CGRP_DEAD.patch
> 0003-cgroup-reorganize-cgroup-bootstrapping.patch
> 0004-cgroup-use-cgroup_setup_root-to-initialize-cgroup_du.patch
> 0005-cgroup-remove-NULL-checks-from-pr_cont_-cgroup_-name.patch
> 0006-cgroup-treat-cgroup_dummy_root-as-an-equivalent-hier.patch
> 0007-cgroup-move-subsys_mask-from-cgroupfs_root-to-cgroup.patch
> 0008-cgroup-rename-cgroup_dummy_root-and-related-names.patch
> 0009-cgroup-drop-const-from-buffer-of-cftype-write_string.patch
> 0010-cgroup-make-cgrp_dfl_root-mountable.patch
> 0011-cgroup-implement-CFTYPE_ONLY_ON_DFL.patch
>
> 0001-0002 are misc fix / prep.
>
> 0003-0009 (mostly) turn the dummy hierarchy into a full hierarchy
> which takes on controllers which aren't attached to other hierarchies.
>
> 0010-0011 make the default hierarchy mountable and implement
> CFTYPE_ONLY_DFL.
>
> This patchset is on top of cgroup/for-3.15 b8dadcb58d54 ("cpuset: use
> rcu_read_lock() to protect task_cs()"). diffstat follows.
>
> block/blk-throttle.c |4
> block/cfq-iosched.c |4
> include/linux/cgroup.h| 57 ++---
> kernel/cgroup.c | 464
> +-
> kernel/cgroup_freezer.c |2
> kernel/cpuset.c |2
> mm/hugetlb_cgroup.c |2
> mm/memcontrol.c |4
> net/core/netprio_cgroup.c |2
> net/ipv4/tcp_memcontrol.c |2
> security/device_cgroup.c |4
> 11 files changed, 295 insertions(+), 252 deletions(-)
>
Looks good in general!
Acked-by: Li Zefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: slicoss: Fix prefer ether_addr_copy over memcpy
On Tue, 2014-03-18 at 12:38 +0900, Jingoo Han wrote:
> In addition to this, there are the same cases like this,
> in this file as below. Please search other same cases.
> For instance, 'grep' will be a good way to find it.
[]
> static void slic_adapter_set_hwaddr(struct adapter *adapter)
> {
> struct sliccard *card = adapter->card;
[]
> if (is_zero_ether_addr(adapter->currmacaddr))
> memcpy(adapter->currmacaddr, adapter->macaddr,
>ETH_ALEN);
> if (adapter->netdev)
> memcpy(adapter->netdev->dev_addr,
> adapter->currmacaddr,
>ETH_ALEN);
> }
> }
>
> Joe Perches,
> These are not spotted by checkpatch.pl.
> However, after modifying it as below, checkpatch warnings are
> printed. Would you confirm it?
If it's not on a single line, checkpatch won't find it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] random: Add arch_has_random[_seed]()
On Mon, 2014-03-17 at 16:36 -0700, H. Peter Anvin wrote:
> Add predicate functions for having arch_get_random[_seed]*(). The
> only current use is to avoid the loop in arch_random_refill() when
> arch_get_random_seed_long() is unavailable.
Paul, I think our HW rng on P7+ and later would qualify no ?
Cheers,
Ben.
> Signed-off-by: H. Peter Anvin
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> ---
> arch/powerpc/include/asm/archrandom.h | 9 +
> arch/x86/include/asm/archrandom.h | 3 +++
> drivers/char/random.c | 3 +++
> include/linux/random.h| 8
> 4 files changed, 23 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/archrandom.h
> b/arch/powerpc/include/asm/archrandom.h
> index 801beba..bde5311 100644
> --- a/arch/powerpc/include/asm/archrandom.h
> +++ b/arch/powerpc/include/asm/archrandom.h
> @@ -25,6 +25,11 @@ static inline int arch_get_random_int(unsigned int *v)
> return rc;
> }
>
> +static inline int arch_has_random(void)
> +{
> + return !!ppc_md.get_random_long;
> +}
> +
> int powernv_get_random_long(unsigned long *v);
>
> static inline int arch_get_random_seed_long(unsigned long *v)
> @@ -35,6 +40,10 @@ static inline int arch_get_random_seed_int(unsigned int *v)
> {
> return 0;
> }
> +static inline int arch_has_random_seed(void)
> +{
> + return 0;
> +}
>
> #endif /* CONFIG_ARCH_RANDOM */
>
> diff --git a/arch/x86/include/asm/archrandom.h
> b/arch/x86/include/asm/archrandom.h
> index ba064d5..c7ed4a6 100644
> --- a/arch/x86/include/asm/archrandom.h
> +++ b/arch/x86/include/asm/archrandom.h
> @@ -100,6 +100,9 @@ GET_SEED(arch_get_random_seed_int, unsigned int,
> RDSEED_INT, ASM_NOP4);
>
> #endif /* CONFIG_X86_64 */
>
> +#define arch_has_random()static_cpu_has(X86_FEATURE_RDRAND)
> +#define arch_has_random_seed() static_cpu_has(X86_FEATURE_RDSEED)
> +
> #endif /* CONFIG_ARCH_RANDOM */
>
> extern void x86_init_rdrand(struct cpuinfo_x86 *c);
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index c35cee2..6b75713 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -1307,6 +1307,9 @@ static int arch_random_refill(void)
> unsigned int i;
> unsigned long buf[nlongs];
>
> + if (!arch_has_random_seed())
> + return 0;
> +
> for (i = 0; i < nlongs; i++) {
> if (arch_get_random_seed_long([n]))
> n++;
> diff --git a/include/linux/random.h b/include/linux/random.h
> index ddaddec..e7a221a 100644
> --- a/include/linux/random.h
> +++ b/include/linux/random.h
> @@ -72,6 +72,10 @@ static inline int arch_get_random_int(unsigned int *v)
> {
> return 0;
> }
> +static inline int arch_has_random(void)
> +{
> + return 0;
> +}
> static inline int arch_get_random_seed_long(unsigned long *v)
> {
> return 0;
> @@ -80,6 +84,10 @@ static inline int arch_get_random_seed_int(unsigned int *v)
> {
> return 0;
> }
> +static inline int arch_has_random_seed(void)
> +{
> + return 0;
> +}
> #endif
>
> /* Pseudo random number generator from numerical recipes. */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: slicoss: Fix prefer ether_addr_copy over memcpy
On Tuesday, March 18, 2014 12:18 PM, Joel Pelaez Jorge wrote:
>
> This patch fixes the following checkpatch.pl issues caused by the new
> function: ether_addr_copy
>
> Signed-off-by: Joel Pelaez Jorge
> ---
> diff --git a/drivers/staging/slicoss/slicoss.c
> b/drivers/staging/slicoss/slicoss.c
> index 12aafe3..4ff39aa 100644
> --- a/drivers/staging/slicoss/slicoss.c
> +++ b/drivers/staging/slicoss/slicoss.c
> @@ -2313,7 +2313,7 @@ static int slic_mcast_add_list(struct adapter
> *adapter, char *address)
> if (mcaddr == NULL)
> return 1;
>
> -memcpy(mcaddr->address, address, ETH_ALEN);
> +ether_addr_copy(mcaddr->address, address);
In addition to this, there are the same cases like this,
in this file as below. Please search other same cases.
For instance, 'grep' will be a good way to find it.
static void slic_adapter_set_hwaddr(struct adapter *adapter)
{
struct sliccard *card = adapter->card;
if ((adapter->card) && (card->config_set)) {
memcpy(adapter->macaddr,
card->config.MacInfo[adapter->functionnumber].macaddrA,
sizeof(struct slic_config_mac));
if (is_zero_ether_addr(adapter->currmacaddr))
memcpy(adapter->currmacaddr, adapter->macaddr,
ETH_ALEN);
if (adapter->netdev)
memcpy(adapter->netdev->dev_addr, adapter->currmacaddr,
ETH_ALEN);
}
}
Joe Perches,
These are not spotted by checkpatch.pl.
However, after modifying it as below, checkpatch warnings are
printed. Would you confirm it?
if (is_zero_ether_addr(adapter->currmacaddr))
memcpy(adapter->currmacaddr, adapter->macaddr, ETH_ALEN);
if (adapter->netdev)
memcpy(adapter->netdev->dev_addr, adapter->currmacaddr,
ETH_ALEN);
}
Best regards,
Jingoo Han
>
> mcaddr->next = adapter->mcastaddrs;
> adapter->mcastaddrs = mcaddr;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: dgap: Fixed sparse error: same symbol redeclared with different type
sparse reported dgap_do_fep_load is redeclared with different type. while
fixing, I noticed __user attribute is used incorrectly in declaration.
There is no need to define __user for firware->data.
Replaced the __user with 'const uchar *' from function dgap_do_fep_load and
did the same for function dgap_do_bios_load
patch generated against: next-20140317
Signed-off-by: Masood Mehmood
---
drivers/staging/dgap/dgap.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index bfafe7e..bbacbba 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -210,9 +210,8 @@ static uint dgap_config_get_useintr(struct board_t *bd);
static uint dgap_config_get_altpin(struct board_t *bd);
static int dgap_ms_sleep(ulong ms);
-static void dgap_do_bios_load(struct board_t *brd, uchar __user *ubios,
- int len);
-static void dgap_do_fep_load(struct board_t *brd, uchar __user *ufep, int len);
+static void dgap_do_bios_load(struct board_t *brd, const uchar *ubios, int
len);
+static void dgap_do_fep_load(struct board_t *brd, const uchar *ufep, int len);
#ifdef DIGI_CONCENTRATORS_SUPPORTED
static void dgap_do_conc_load(struct board_t *brd, uchar *uaddr, int len);
#endif
@@ -936,7 +935,7 @@ static int dgap_firmware_load(struct pci_dev *pdev, int
card_type)
fw_info[card_type].bios_name);
return ret;
}
- dgap_do_bios_load(brd, (char *)fw->data, fw->size);
+ dgap_do_bios_load(brd, fw->data, fw->size);
release_firmware(fw);
/* Wait for BIOS to test board... */
@@ -954,7 +953,7 @@ static int dgap_firmware_load(struct pci_dev *pdev, int
card_type)
fw_info[card_type].fep_name);
return ret;
}
- dgap_do_fep_load(brd, (char *)fw->data, fw->size);
+ dgap_do_fep_load(brd, fw->data, fw->size);
release_firmware(fw);
/* Wait for FEP to load on board... */
@@ -4350,7 +4349,7 @@ static int dgap_tty_register_ports(struct board_t *brd)
* Copies the BIOS code from the user to the board,
* and starts the BIOS running.
*/
-static void dgap_do_bios_load(struct board_t *brd, uchar __user *ubios, int
len)
+static void dgap_do_bios_load(struct board_t *brd, const uchar *ubios, int len)
{
uchar *addr;
uint offset;
@@ -4426,7 +4425,7 @@ static void dgap_do_wait_for_bios(struct board_t *brd)
* Copies the FEP code from the user to the board,
* and starts the FEP running.
*/
-static void dgap_do_fep_load(struct board_t *brd, uchar *ufep, int len)
+static void dgap_do_fep_load(struct board_t *brd, const uchar *ufep, int len)
{
uchar *addr;
uint offset;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/12] scsi/NCR5380: fix debugging macros and #include structure
On Tue, 2014-03-18 at 11:28 +1100, Finn Thain wrote: > This patch series addresses several issues with NCR5380 drivers: [] > 3. Broken debugging code. My preference would be to change dprintk to scsi_dbg Seems sensible otherwise. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: slicoss: Fix prefer ether_addr_copy over memcpy
This patch fixes the following checkpatch.pl issues caused by the new function: ether_addr_copy Signed-off-by: Joel Pelaez Jorge --- diff --git a/drivers/staging/slicoss/slicoss.c b/drivers/staging/slicoss/slicoss.c index 12aafe3..4ff39aa 100644 --- a/drivers/staging/slicoss/slicoss.c +++ b/drivers/staging/slicoss/slicoss.c @@ -2313,7 +2313,7 @@ static int slic_mcast_add_list(struct adapter *adapter, char *address) if (mcaddr == NULL) return 1; -memcpy(mcaddr->address, address, ETH_ALEN); +ether_addr_copy(mcaddr->address, address); mcaddr->next = adapter->mcastaddrs; adapter->mcastaddrs = mcaddr; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] perf: Fix a race between ring_buffer_detach() and ring_buffer_wakeup()
On Mon, Mar 17, 2014 at 06:30:38PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 17, 2014 at 09:48:15AM -0700, Paul E. McKenney wrote:
> > Good point, this barrier is a bit obsure. Here you go:
> >
> > /*
> > * Make sure this load happens before the purportedly
> > * time-consuming work between get_state_synchronize_rcu()
> > * and cond_synchronize_rcu().
> > */
> >
> > So all you lose by leaving this barrier out is a slightly higher
> > probability of invoking synchronize_rcu() at cond_synchronize_rcu() time.
> > And without the barrier there is some chance of the CPU doing the load in
> > cond_synchronize_rcu() before this load in get_state_synchronize_rcu().
> > Which should be OK, but simpler to exclude this than have to worry about
> > counters out of sync. Besides, you are taking a grace-period delay in
> > here somewhere, so the memory barrier is way down in the noise.
>
> Oh sure; expense wasn't my concern. But I always question barriers
> without comments, and I couldn't come up with a reason for this one.
>
> > > The way I imaged using this is taking this snapshot after the RCU
> > > operation, such that we err towards seeing a later grace period and
> > > synchronizing too much in stead of seeing an earlier and sync'ing too
> > > little.
> > >
> > > Such use would suggest the barrier the other way around.
> >
> > Ah, but that ordering happens at the updater's end. And there
> > are in fact memory barriers before and after the increment of
> > ->gpnum in rcu_gp_init():
> >
> > /* Advance to a new grace period and initialize state. */
> > record_gp_stall_check_time(rsp);
> > /* Record GP times before starting GP, hence smp_store_release(). */
> > smp_store_release(>gpnum, rsp->gpnum + 1);
> > trace_rcu_grace_period(rsp->name, rsp->gpnum, TPS("start"));
> > raw_spin_unlock_irq(>lock);
> >
> > /* Exclude any concurrent CPU-hotplug operations. */
> > mutex_lock(>onoff_mutex);
> > smp_mb__after_unlock_lock(); /* ->gpnum increment before GP! */
> >
> > The smp_store_release() provides the memory barrier before, and the
> > smp_mb__after_unlock_lock() provides it after.
>
> That wasn't exactly what I was talking about.
>
> So suppose:
>
> spin_lock()
> list_del_rcu(>foo);
> spin_unlock();
>
> rcu_stamp = get_state_sync_rcu();
>
> Now we very much want to ensure to get the gpnum _after_ completing that
> list_del_rcu(), because if we were to observe the gpnum before it could
> complete before and we'd fail to wait long enough.
>
> Now in the above, and with your proposed implementation, there is in
> fact no guarantee the load doesn't slip up past the list_del_rcu().
>
> The RELEASE per the spin_unlock() only guarantees the list_del_rcu()
> happens before it, but the gpnum load can slip in, and in fact pass over
> the list_del_rcu().
Right you are! Fixed patch below.
> > > > +void cond_synchronize_rcu(unsigned long oldstate)
> > > > +{
> > > > + unsigned long newstate =
> > > > smp_load_acquire(_state->completed);
> > >
> > > Again, uncommented barriers; the load_acquire seems to suggest you want
> > > to make sure the sync_rcu() bits happen after this read. But seeing how
> > > sync_rcu() will invariably read the same data again and you get an
> > > address dep this seems somewhat superfluous.
> >
> > Not quite! The get_state_synchronize_rcu() function reads ->gpnum,
> > but cond_synchronize_rcu() reads ->completed. The
>
> I was talking about the synchronize_rcu() call later in
> cond_synchronize_rcu().
>
> But looking at its implementation; they don't in fact load either gpnum
> or completed.
They don't directly, but they register callbacks, which causes the
RCU core code to access them. But if we invoke synchronize_rcu(),
it really doesn't matter what either get_state_synchronize_rcu() or
cond_synchronize_rcu(). The memory barrier from cond_synchronize_rcu()'s
smp_load_acquire() is instead needed for the case where we -don't-
invoke synchornize_rcu(). In that case, whatever was supposed to follow
the grace period had better really follow the grace period.
> > > > + if (ULONG_CMP_GE(oldstate, newstate))
> > >
> > > So if the observed active gp (oldstate) is ahead or equal to the last
> > > completed gp, then we wait?
> >
> > Yep! I will risk an ASCII diagram:
> >
> >
> > 3:+gpnum+-- ...
> > | |
> > 2: +gpnum+---+--completed--+
> > | |
> > 1:+gpnum+---+--completed--+
> > | |
> > 0: +-+--completed--+
> >
> >
> > A full RCU grace period happens between a pair of "|"s on the same line.
> > By inspection, if your snapshot of ->gpnum is greater than the current
> > value of ->completed, a grace period has passed.
>
> OK, so I get the >
[PATCH 2/3] ARM: at91: pm_slowclock: add enter standby mode for ARMv7
Signed-off-by: Wenyou Yang --- arch/arm/mach-at91/pm_slowclock.S | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-at91/pm_slowclock.S b/arch/arm/mach-at91/pm_slowclock.S index 2001877..842ddaf 100644 --- a/arch/arm/mach-at91/pm_slowclock.S +++ b/arch/arm/mach-at91/pm_slowclock.S @@ -102,6 +102,20 @@ tmp2 .reqr5 2: .endm +/* + * Put the processor to enter into Standby mode, wait for interrupt to wakeup + */ + .macro _do_wfi + +#if defined(CONFIG_CPU_V7) + dsb + wfi @ Wait For Interrupt +#else + mcr p15, 0, tmp1, c7, c0, 4 +#endif + + .endm + .text /* void at91_slow_clock(void __iomem *pmc, void __iomem *sdramc, @@ -220,7 +234,7 @@ sdr_sr_done: str tmp1, [pmc, #AT91_CKGR_MOR] /* Wait for interrupt */ - mcr p15, 0, tmp1, c7, c0, 4 + _do_wfi /* Turn on the main oscillator */ ldr tmp1, [pmc, #AT91_CKGR_MOR] -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] defconfig: arm: sama5_defconfig: update
Due to enable CONFIG_AT91_SLOW_CLOCK Signed-off-by: Wenyou Yang --- arch/arm/configs/sama5_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig index dc3881e..a15879c 100644 --- a/arch/arm/configs/sama5_defconfig +++ b/arch/arm/configs/sama5_defconfig @@ -201,3 +201,4 @@ CONFIG_CRYPTO_DEV_ATMEL_TDES=y CONFIG_CRYPTO_DEV_ATMEL_SHA=y CONFIG_CRC_CCITT=m CONFIG_CRC_ITU_T=m +CONFIG_AT91_SLOW_CLOCK=y -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] ARM: at91: add enter standby mode for ARMv7
Hi Nicolas, The patches is to add support to enter standby mode for ARMv7, then enabling the feature to disable main oscillator when suspending to memory for sama5d3x. The patches is based on branch, for-next and at91/cleanup git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git Best Regards, Wenyou Yang Wenyou Yang (3): ARM: at91: pm: add the socs support the DDRC controller ARM: at91: pm_slowclock: add enter standby mode for ARMv7 defconfig: arm: sama5_defconfig: update arch/arm/configs/sama5_defconfig |1 + arch/arm/mach-at91/pm.c |5 - arch/arm/mach-at91/pm_slowclock.S | 16 +++- 3 files changed, 20 insertions(+), 2 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ARM: at91: pm: add the socs support the DDRC controller
socs: at91sam9x5, at91sam9n12, sama5d3 Signed-off-by: Wenyou Yang --- arch/arm/mach-at91/pm.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c index 8bda1ce..7280d09 100644 --- a/arch/arm/mach-at91/pm.c +++ b/arch/arm/mach-at91/pm.c @@ -238,7 +238,10 @@ static int at91_pm_enter(suspend_state_t state) if (cpu_is_at91rm9200()) memctrl = AT91_MEMCTRL_MC; - else if (cpu_is_at91sam9g45()) + else if (cpu_is_at91sam9g45() + || cpu_is_at91sam9x5() + || cpu_is_at91sam9n12() + || cpu_is_sama5d3()) memctrl = AT91_MEMCTRL_DDRSDR; #ifdef CONFIG_AT91_SLOW_CLOCK /* copy slow_clock handler to SRAM, and call it */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kmemcheck: move hook into __alloc_pages_nodemask() for the page allocator
Now kmemcheck_pagealloc_alloc() is only called by __alloc_pages_slowpath(). __alloc_pages_nodemask() __alloc_pages_slowpath() kmemcheck_pagealloc_alloc() And the page will not be tracked by kmemcheck in the following path. __alloc_pages_nodemask() get_page_from_freelist() So move kmemcheck_pagealloc_alloc() into __alloc_pages_nodemask(), like this: __alloc_pages_nodemask() ... get_page_from_freelist() if (!page) __alloc_pages_slowpath() kmemcheck_pagealloc_alloc() ... Signed-off-by: Xishi Qiu --- mm/page_alloc.c |6 ++ 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index e3758a0..ce596b4 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2671,11 +2671,7 @@ rebalance: nopage: warn_alloc_failed(gfp_mask, order, NULL); - return page; got_pg: - if (kmemcheck_enabled) - kmemcheck_pagealloc_alloc(page, order, gfp_mask); - return page; } @@ -2748,6 +2744,8 @@ retry_cpuset: preferred_zone, migratetype); } + if (kmemcheck_enabled && page) + kmemcheck_pagealloc_alloc(page, order, gfp_mask); trace_mm_page_alloc(page, order, gfp_mask, migratetype); out: -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/3] ARM: dts: berlin2q: add the Marvell Armada 1500 pro
Hi Antoine,
On Mon, 17 Mar 2014 08:06:26 -0700
Antoine Ténart wrote:
> Adds initial support for the Marvell Armada 1500 pro (BG2Q) SoC (Berlin
> family). The SoC has nodes for cpu, l2 cache controller, interrupt
> controllers, local timer, apb timers and uarts for now.
>
> Signed-off-by: Antoine Ténart
> Signed-off-by: Alexandre Belloni
> ---
> arch/arm/boot/dts/berlin2q.dtsi | 210
> 1 file changed, 210 insertions(+)
> create mode 100644 arch/arm/boot/dts/berlin2q.dtsi
>
> diff --git a/arch/arm/boot/dts/berlin2q.dtsi
> b/arch/arm/boot/dts/berlin2q.dtsi new file mode 100644
> index ..7a50267b1044
> --- /dev/null
> +++ b/arch/arm/boot/dts/berlin2q.dtsi
> @@ -0,0 +1,210 @@
> +/*
> + * Copyright (C) 2014 Antoine Ténart
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include
> +
> +#include "skeleton.dtsi"
> +
> +/ {
> + model = "Marvell Armada 1500 pro (BG2-Q) SoC";
> + compatible = "marvell,berlin2q", "marvell,berlin";
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + compatible = "arm,cortex-a9";
> + device_type = "cpu";
> + next-level-cache = <>;
> + reg = <0>;
> + };
> +
> + cpu@1 {
> + compatible = "arm,cortex-a9";
> + device_type = "cpu";
> + next-level-cache = <>;
> + reg = <1>;
> + };
> +
> + cpu@2 {
> + compatible = "arm,cortex-a9";
> + device_type = "cpu";
> + next-level-cache = <>;
> + reg = <2>;
> + };
> +
> + cpu@3 {
> + compatible = "arm,cortex-a9";
> + device_type = "cpu";
> + next-level-cache = <>;
> + reg = <3>;
> + };
> + };
> +
> + smclk: sysmgr-clock {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <2500>;
> + };
> +
> + cpuclk: cpu-clock {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <12>;
> + };
> +
> + sysclk: system-clock {
> + compatible = "fixed-factor-clock";
> + #clock-cells = <0>;
> + clocks = <>;
> + clock-multi = <1>;
> + clock-div = <3>;
> + };
Can you please name it as twdclk to avoid confusion? On Berlin, sysclk is
another
clk rather than the clk for twd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: cond_resched() and RCU CPU stall warnings
On Mon, Mar 17, 2014 at 06:14:34PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 17, 2014 at 09:58:07AM -0700, Paul E. McKenney wrote:
> > @@ -4111,6 +4115,7 @@ int __sched __cond_resched_softirq(void)
> > {
> > BUG_ON(!in_softirq());
> >
> > + rcu_cond_resched();
>
> Don't you have to enable BHs before doing that? And if not; that needs a
> comment for sure! :-)
No need to enable BHs, just RCU marking quiescent states. But yes,
the name does look a bit scary in that context, doesn't it? Added
a comment, please see below for updated patch.
> > if (should_resched()) {
> > local_bh_enable();
> > __cond_resched();
> >
torture: Better summary diagnostics for build failures
The reaction of kvm-recheck.sh is obscure at best, and easy to miss
completely. This commit therefore prints "BUG: Build failed" in the
summary at the end of a run.
Signed-off-by: Paul E. McKenney
diff --git a/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh
b/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh
index 829186e19eb1..7f1ff1a8fc4b 100755
--- a/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh
+++ b/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh
@@ -35,7 +35,7 @@ configfile=`echo $i | sed -e 's/^.*\///'`
ncs=`grep "Writes: Total:" $i/console.log 2> /dev/null | tail -1 | sed -e
's/^.* Total: //' -e 's/ .*$//'`
if test -z "$ncs"
then
- echo $configfile
+ echo "$configfile ---"
else
title="$configfile --- $ncs acquisitions/releases"
dur=`sed -e 's/^.* locktorture.shutdown_secs=//' -e 's/ .*$//' <
$i/qemu-cmd 2> /dev/null`
diff --git a/tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh
b/tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh
index d75b1dc5ae53..307c4b95f325 100755
--- a/tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh
+++ b/tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh
@@ -35,7 +35,7 @@ configfile=`echo $i | sed -e 's/^.*\///'`
ngps=`grep ver: $i/console.log 2> /dev/null | tail -1 | sed -e 's/^.* ver: //'
-e 's/ .*$//'`
if test -z "$ngps"
then
- echo $configfile
+ echo "$configfile ---"
else
title="$configfile --- $ngps grace periods"
dur=`sed -e 's/^.* rcutorture.shutdown_secs=//' -e 's/ .*$//' <
$i/qemu-cmd 2> /dev/null`
diff --git a/tools/testing/selftests/rcutorture/bin/kvm-recheck.sh
b/tools/testing/selftests/rcutorture/bin/kvm-recheck.sh
index 26d78b7eaccf..ee1f6cae3d70 100755
--- a/tools/testing/selftests/rcutorture/bin/kvm-recheck.sh
+++ b/tools/testing/selftests/rcutorture/bin/kvm-recheck.sh
@@ -25,6 +25,7 @@
# Authors: Paul E. McKenney
PATH=`pwd`/tools/testing/selftests/rcutorture/bin:$PATH; export PATH
+. tools/testing/selftests/rcutorture/bin/functions.sh
for rd in "$@"
do
firsttime=1
@@ -39,13 +40,24 @@ do
fi
TORTURE_SUITE="`cat $i/../TORTURE_SUITE`"
kvm-recheck-${TORTURE_SUITE}.sh $i
- configcheck.sh $i/.config $i/ConfigFragment
- parse-build.sh $i/Make.out $configfile
- parse-torture.sh $i/console.log $configfile
- parse-console.sh $i/console.log $configfile
- if test -r $i/Warnings
+ if test -f "$i/console.log"
then
- cat $i/Warnings
+ configcheck.sh $i/.config $i/ConfigFragment
+ parse-build.sh $i/Make.out $configfile
+ parse-torture.sh $i/console.log $configfile
+ parse-console.sh $i/console.log $configfile
+ if test -r $i/Warnings
+ then
+ cat $i/Warnings
+ fi
+ else
+ if test -f "$i/qemu-cmd"
+ then
+ print_bug qemu failed
+ else
+ print_bug Build failed
+ fi
+ echo " $i"
fi
done
done
diff --git a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
b/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
index 7a95f86cc85a..51c34a91a375 100755
--- a/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
+++ b/tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh
@@ -106,6 +106,7 @@ then
fi
else
cp $builddir/Make*.out $resdir
+ cp $builddir/.config $resdir || :
echo Build failed, not running KVM, see $resdir.
if test -f $builddir.wait
then
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ PATCH 0/8] sched: remove cpu_load array
On 03/17/2014 11:24 AM, Alex Shi wrote: > On 03/13/2014 01:57 PM, Alex Shi wrote: >> In the cpu_load decay usage, we mixed the long term, short term load with >> balance bias, randomly pick a big/small value from them according to balance >> destination or source. This mix is wrong, the balance bias should be based >> on task moving cost between cpu groups, not on random history or instant >> load. >> History load maybe diverage a lot from real load, that lead to incorrect >> bias. >> >> In fact, the cpu_load decays can be replaced by the sched_avg decay, that >> also decays load on time. The balance bias part can fully use fixed bias -- >> imbalance_pct, which is already used in newly idle, wake, forkexec balancing >> and numa balancing scenarios. >> >> Currently the only working idx is busy_idx and idle_idx. >> As to busy_idx: >> We mix history load decay and bias together. The ridiculous thing is, when >> all cpu load are continuous stable, long/short term load is same. then we >> lose the bias meaning, so any minimum imbalance may cause unnecessary task >> moving. To prevent this funny thing happen, we have to reuse the >> imbalance_pct again in find_busiest_group(). But that clearly causes over >> bias in normal time. If there are some burst load in system, it is more >> worse. >> > > Any comments? IMHO, task moving resistance, bias, is only related with task migration cost. no relationship with history load. Another issue of history load mix with bias is that we want to care the history load impact, but it is often ignored when instant load is fit bias required more -- bigger in destination or smaller in source. Any comments on this? :) > >> As to idle_idx: >> Though I have some concern of usage correction, >> https://lkml.org/lkml/2014/3/12/247, but since we are working on cpu >> idle migration into scheduler. The problem will be reconsidered. We don't >> need to care it now. >> >> This patch removed the cpu_load idx decay, since it can be replaced by >> sched_avg feature. and left the imbalance_pct bias untouched, since only >> idle_idx missed it, but it is fine. and will be reconsidered soon. >> >> >> V5, >> 1, remove unify bias patch and biased_load function. Thanks for PeterZ's >> comments! >> 2, remove get_sd_load_idx() in the 1st patch as SrikarD's suggestion. >> 3, remove LB_BIAS feature, it is not needed now. > > -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Regression, bisected 9e30cc] "sysfs, kernfs: no need to kern_mount() sysfs from sysfs_init()" prevents system from booting correctly
By the way, I tried to get the error message, but my display had gone in standby mode before it completed and it wouldn't wake up. I'll have to test with an earlier 3.14 kernel (rc1 or rc2), when it was answering to my wake up signal. Even though my display doesn't wake up with rc6, it is still running since I can see some activities on my disk from time to time. I'll be back with more info ASAP. Alexandre Demers On Mon 17 Mar 2014 04:13:46 PM EDT, Tejun Heo wrote: Hello, On Fri, Mar 14, 2014 at 11:48:10AM -0400, Alexandre Demers wrote: Since it takes a while before the system begins to display errors, I'll have to test it and report it later today when I'll get back from work. Any update? Now, about the userland part, this seems a broad question... I'm using Arch Linux 64bit (updated mostly on a daily basis). But I suspect you are expecting a narrower information. Is there anything in particular you want to know? I was just wondering whether you were running something really exotic. Doesn't seem that way. Weird that other people aren't hitting this issue. Hmm... Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] mmc: rtsx: modify error handle and remove smatch warnings
From: Micky Ching
Using non-DMA dump-regs, which would be more exactly for DMA transfer failed.
More careful handle when cmd/data timeout, add stop(CMD12) cmd before go to
finish request when multi-rw timeout.
Remove some static checher warings.
on commit:
drivers/mmc/host/rtsx_pci_sdmmc.c:194 sd_finish_request()
error: we previously assumed 'mrq' could be null (see line 158)
drivers/mmc/host/rtsx_pci_sdmmc.c:504 sd_get_rsp()
error: we previously assumed 'cmd' could be null (see line 434)
drivers/mmc/host/rtsx_pci_sdmmc.c:525 sd_pre_dma_transfer()
warn: we tested 'next' before and it was 'false'
Signed-off-by: Micky Ching
---
drivers/mmc/host/rtsx_pci_sdmmc.c | 118 -
1 file changed, 64 insertions(+), 54 deletions(-)
diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 0d8904a..d00a94e 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -81,25 +81,23 @@ static inline void sd_clear_error(struct realtek_pci_sdmmc
*host)
}
#ifdef DEBUG
+static inline void sd_print_reg(struct realtek_pci_sdmmc *host, u16 reg)
+{
+ u8 val;
+ if (rtsx_pci_read_register(host->pcr, reg, ) < 0)
+ dev_dbg(sdmmc_dev(host), "read 0x%04x failed\n", reg);
+ else
+ dev_dbg(sdmmc_dev(host), "0x%04X: 0x%02x\n", reg, val);
+}
+
static void sd_print_debug_regs(struct realtek_pci_sdmmc *host)
{
- struct rtsx_pcr *pcr = host->pcr;
u16 i;
- u8 *ptr;
-
- /* Print SD host internal registers */
- rtsx_pci_init_cmd(pcr);
- for (i = 0xFDA0; i <= 0xFDAE; i++)
- rtsx_pci_add_cmd(pcr, READ_REG_CMD, i, 0, 0);
- for (i = 0xFD52; i <= 0xFD69; i++)
- rtsx_pci_add_cmd(pcr, READ_REG_CMD, i, 0, 0);
- rtsx_pci_send_cmd(pcr, 100);
- ptr = rtsx_pci_get_cmd_data(pcr);
for (i = 0xFDA0; i <= 0xFDAE; i++)
- dev_dbg(sdmmc_dev(host), "0x%04X: 0x%02x\n", i, *(ptr++));
+ sd_print_reg(host, i);
for (i = 0xFD52; i <= 0xFD69; i++)
- dev_dbg(sdmmc_dev(host), "0x%04X: 0x%02x\n", i, *(ptr++));
+ sd_print_reg(host, i);
}
#else
#define sd_print_debug_regs(host)
@@ -125,19 +123,27 @@ static void sd_request_timeout(unsigned long host_addr)
spin_lock_irqsave(>lock, flags);
if (!host->mrq) {
- dev_err(sdmmc_dev(host), "error: no request exist\n");
- goto out;
+ dev_err(sdmmc_dev(host), "error: request not exist\n");
+ spin_unlock_irqrestore(>lock, flags);
+ return;
}
- if (host->cmd)
+ if (host->cmd && host->data)
+ dev_err(sdmmc_dev(host), "error: cmd and data conflict\n");
+
+ if (host->cmd) {
host->cmd->error = -ETIMEDOUT;
- if (host->data)
- host->data->error = -ETIMEDOUT;
+ dev_dbg(sdmmc_dev(host), "timeout for cmd %d\n",
+ host->cmd->opcode);
+ tasklet_schedule(>cmd_tasklet);
+ }
- dev_dbg(sdmmc_dev(host), "timeout for request\n");
+ if (host->data) {
+ host->data->error = -ETIMEDOUT;
+ dev_dbg(sdmmc_dev(host), "timeout for data transfer\n");
+ tasklet_schedule(>data_tasklet);
+ }
-out:
- tasklet_schedule(>finish_tasklet);
spin_unlock_irqrestore(>lock, flags);
}
@@ -157,7 +163,8 @@ static void sd_finish_request(unsigned long host_addr)
mrq = host->mrq;
if (!mrq) {
dev_err(sdmmc_dev(host), "error: no request need finish\n");
- goto out;
+ spin_unlock_irqrestore(>lock, flags);
+ return;
}
cmd = mrq->cmd;
@@ -167,11 +174,6 @@ static void sd_finish_request(unsigned long host_addr)
(mrq->stop && mrq->stop->error) ||
(cmd && cmd->error) || (data && data->error);
- if (any_error) {
- rtsx_pci_stop_cmd(pcr);
- sd_clear_error(host);
- }
-
if (data) {
if (any_error)
data->bytes_xfered = 0;
@@ -188,7 +190,6 @@ static void sd_finish_request(unsigned long host_addr)
host->cmd = NULL;
host->data = NULL;
-out:
spin_unlock_irqrestore(>lock, flags);
mutex_unlock(>pcr_mutex);
mmc_request_done(host->mmc, mrq);
@@ -373,8 +374,11 @@ static void sd_send_cmd(struct realtek_pci_sdmmc *host,
struct mmc_command *cmd)
if (cmd->opcode == SD_SWITCH_VOLTAGE) {
err = rtsx_pci_write_register(pcr, SD_BUS_STAT,
0xFF, SD_CLK_TOGGLE_EN);
- if (err < 0)
+ if (err < 0) {
+ rtsx_pci_write_register(pcr, SD_BUS_STAT,
+ SD_CLK_TOGGLE_EN | SD_CLK_FORCE_STOP, 0);
goto out;
+
[PATCH 1/2] mmc: rtsx: add R1-no-CRC mmc command type handle
From: Micky Ching commit a27fbf2f067b0cd6f172c8b696b9a44c58bfaa7a produced a cmd.flags unhandled in realtek pci host driver. This will make MMC card failed initialize, this patch is used to handle the new cmd.flags condition and MMC card can be used. Signed-off-by: Micky Ching --- drivers/mmc/host/rtsx_pci_sdmmc.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c b/drivers/mmc/host/rtsx_pci_sdmmc.c index 5fb994f..0d8904a 100644 --- a/drivers/mmc/host/rtsx_pci_sdmmc.c +++ b/drivers/mmc/host/rtsx_pci_sdmmc.c @@ -346,6 +346,9 @@ static void sd_send_cmd(struct realtek_pci_sdmmc *host, struct mmc_command *cmd) case MMC_RSP_R1: rsp_type = SD_RSP_TYPE_R1; break; + case MMC_RSP_R1 & ~MMC_RSP_CRC: + rsp_type = SD_RSP_TYPE_R1 | SD_NO_CHECK_CRC7; + break; case MMC_RSP_R1B: rsp_type = SD_RSP_TYPE_R1b; break; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] add new cmd type handle and remove smatch warnings
From: Micky Ching Add new command type(R1 without CRC) handle, without this patch mmc card initialize will be failed. Using a more careful handle in request timeout, and debug info is printed using non DMA mode. Smatch warning was removed. Micky Ching (2): mmc: rtsx: add R1-no-CRC mmc command type handle mmc: rtsx: modify error handle and remove smatch warnings drivers/mmc/host/rtsx_pci_sdmmc.c | 121 - 1 file changed, 67 insertions(+), 54 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] net: cdc_ncm: respect operator preferred MTU reported by MBIM
From: Ben Chan Date: Mon, 17 Mar 2014 17:46:27 -0700 > Thanks again for the review and tip. I've submitted patch v2 to > address the le16_to_cpu conversion. When you update a patch from a series, you should repost the entire patch set, rather than just the patch which changes. This avoids any and all ambiguity of which patches go with which others. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: slicoss: Fix prefer ether_addr_copy over memcpy
This patch fixes the following checkpatch.pl issues caused by the new function: ether_addr_copy Signed-off-by: Joel Pelaez Jorge --- diff --git a/drivers/staging/slicoss/slicoss.c b/drivers/staging/slicoss/slicoss.c index 12aafe3..4ff39aa 100644 --- a/drivers/staging/slicoss/slicoss.c +++ b/drivers/staging/slicoss/slicoss.c @@ -2313,7 +2313,7 @@ static int slic_mcast_add_list(struct adapter *adapter, char *address) if (mcaddr == NULL) return 1; -memcpy(mcaddr->address, address, ETH_ALEN); +ether_addr_copy(mcaddr->address, address); mcaddr->next = adapter->mcastaddrs; adapter->mcastaddrs = mcaddr; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH 2/2] ACPI: Default disable auto-serialization.
Hi,
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki
> Sent: Tuesday, March 18, 2014 9:13 AM
>
> On Tuesday, March 18, 2014 12:31:54 AM Zheng, Lv wrote:
> > Hi, Rafael
> >
> > > From: Wysocki, Rafael J
> > > Sent: Monday, March 17, 2014 8:09 PM
> > >
> > > On 3/17/2014 5:14 AM, Lv Zheng wrote:
> > > > This feature enabled by the following commit is still under development.
> > > >
> > > >Commit: cd52379678785b02d7a357988cfba214fdaf92f4
> > > >Subject: ACPICA: Add global option to disable method
> > > > auto-serialization.
> > > >This change adds an option to disable the auto-serialization of
> > > >methods that create named objects.
> > > >
> > > > This patch disables it by default temporarily according to the bug
> > > > reports.
> > >
> > > Well, it doesn't restore the 3.14 behavior of acpi_auto_serialize, as
> > > far as I can say, so we can't apply it.
> > >
> > > I still can drop the commits related to auto-serialization from my
> > > acpica branch. Which commits are they?
> >
> > From linux-pm/bleeding-edge branch, I found this series includes the
> > following commits:
> >
> > Commit: a0fd108f2da56b769472fc0095616fb370988516
> > Author: Lv Zheng
> > Subject: ACPI: Rename kernel parameter "acpi_serialize" to
> > "acpi_no_auto_serialize"
> >
> > Commit: 5f1cb4a92e4c4aabd139ff9ca1e11c0e2db2ac59
> > Author: Lv Zheng
> > Subject: ACPICA: Remove global option to serialize all control methods.
> >
> > Commit: cd52379678785b02d7a357988cfba214fdaf92f4
> > Author: Bob Moore
> > Subject: ACPICA: Add global option to disable method auto-serialization.
> >
> > Commit: f56b05bd111b01141ef74568dc4d262c70295d03
> > Author: Lv Zheng
> > Subject: ACPICA: Add additional named objects for the auto-serialize method
> > scan.
> >
> > Commit: 27f1899350a1d6baab117c03c87f0e37730047bd
> > Author: Bob Moore
> > Subject: ACPICA: Add auto-serialization support for ill-behaved control
> > methods.
> >
> > Reverting these commits can restore original Linux behavior.
> > Please check.
>
> OK, I dropped the five commits above from the acpica branch.
>
> Please check if the current ACPICA material in the bleeding-edge branch of
> linux-pm.git looks OK (and let me know either way).
It took me some time to confirm.
I just checked ACPICA code using the ACPICA divergence script.
And checked the Linux side reversal in osl.c/kernel-parameter.txt.
All seem to be OK.
Best regards
-Lv
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [RFC PATCH 0/4] power_supply: Add DT helper function to get power-supply dev from dt
Hi, On 03/18/2014 09:38 AM, s...@ring0.de wrote: > Hi, > > On Mon, Mar 17, 2014 at 09:43:43PM +0900, Chanwoo Choi wrote: >> This patchset add DT helper function to get power-supply device from >> devicetree. >> - of_power_supply_get_dev(struct device *dev, enum power_supply_dev_type >> type, >>int index) >> Power-supply class provides 'power_supply_get_by_name()' to users who want to >> find power-supply device with the name of power-supply device. >> >> If CONFIG_OF is enabled, device drivers which want to get power-supply device >> would directly get the power-supply device from devicetree by using of_power_ >> supply_get_dev(). This function can be used instead of >> power_supply_get_by_name(). >> >> For example, >> [...] > > include/linux/power_supply.h provides the following function already: > > struct power_supply * > power_supply_get_by_phandle(struct device_node *np, const char *property); > OK, thanks for your reply. Dear all, Ignore this patchset. I'll re-send new patchset using power_supply_get_by_phandle(). Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v2 1/9] ptp: introduce programmable pins.
From: Richard Cochran
Date: Sun, 16 Mar 2014 14:29:22 +0100
> + /* Check to see if any other pin previously had this function. */
> + if (mutex_lock_interruptible(>pincfg_mux))
> + return -ERESTARTSYS;
> + for (i = 0; i < info->n_pins; i++) {
> + if (info->pin_config[i].func == func &&
> + info->pin_config[i].chan == chan) {
> + pin1 = >pin_config[i];
> + break;
> + }
> + }
> + mutex_unlock(>pincfg_mux);
...
> + if (mutex_lock_interruptible(>pincfg_mux))
> + return -ERESTARTSYS;
> + pin2->func = func;
> + pin2->chan = chan;
> + if (pin1) {
> + pin1->func = PTP_PF_NONE;
> + pin1->chan = 0;
> + }
> + mutex_unlock(>pincfg_mux);
> +
> + return 0;
This locking seems unnecessarily complex to me. You should be able to
do the stateless sanity checks, take the mutex, then do all of the
rest of the operations until the end of the function before
dropping the lock.
So just take the lock once over the operations that need it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] s390: correct misuses of module_put in appldata_generic_handler.
Thanks Gerald for reviewing and sorry for not elaborated it in the e-mail.
Firstly, I think you can't call module_put after fail try_module_get
Secondly, there exists duplicate module_put on the program path (the last
one is before return 0)
On Mon, Mar 17, 2014 at 9:28 PM, Gerald Schaefer
wrote:
> On Sat, 15 Mar 2014 21:35:40 +0800
> Zhouyi Zhou wrote:
>
>> correct misuses of module_put in appldata_generic_handler
>
> Sorry, I don't see any misuse, could you elaborate?
>
>>
>> Signed-off-by: Zhouyi Zhou
>> ---
>> arch/s390/appldata/appldata_base.c | 3 ---
>> 1 file changed, 3 deletions(-)
>>
>> diff --git a/arch/s390/appldata/appldata_base.c
>> b/arch/s390/appldata/appldata_base.c
>> index 47c8630..683e0282 100644
>> --- a/arch/s390/appldata/appldata_base.c
>> +++ b/arch/s390/appldata/appldata_base.c
>> @@ -343,7 +343,6 @@ appldata_generic_handler(struct ctl_table *ctl, int
>> write,
>> // protect work queue callback
>> if (!try_module_get(ops->owner)) {
>> mutex_unlock(_ops_mutex);
>> - module_put(ops->owner);
>> return -ENODEV;
>> }
>> ops->callback(ops->data); // init record
>> @@ -354,7 +353,6 @@ appldata_generic_handler(struct ctl_table *ctl, int
>> write,
>> if (rc != 0) {
>> pr_err("Starting the data collection for %s "
>> "failed with rc=%d\n", ops->name, rc);
>> - module_put(ops->owner);
>> } else
>> ops->active = 1;
>> } else if ((buf[0] == '0') && (ops->active == 1)) {
>> @@ -365,7 +363,6 @@ appldata_generic_handler(struct ctl_table *ctl, int
>> write,
>> if (rc != 0)
>> pr_err("Stopping the data collection for %s "
>> "failed with rc=%d\n", ops->name, rc);
>> - module_put(ops->owner);
>> }
>> mutex_unlock(_ops_mutex);
>> out:
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[f2fs-dev] [PATCH v2] f2fs: fix incorrect parsing with option string
Previously 'background_gc={on***,off***}' is being parsed as correct option,
with this patch we cloud fix the trivial bug in mount process.
Change log from v1:
o need to check length of parameter suggested by Jaegeuk Kim.
Signed-off-by: Chao Yu
---
fs/f2fs/super.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 057a3ef..dbe402b 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -258,9 +258,9 @@ static int parse_options(struct super_block *sb, char
*options)
if (!name)
return -ENOMEM;
- if (!strncmp(name, "on", 2))
+ if (strlen(name) == 2 && !strncmp(name, "on", 2))
set_opt(sbi, BG_GC);
- else if (!strncmp(name, "off", 3))
+ else if (strlen(name) == 3 && !strncmp(name, "off", 3))
clear_opt(sbi, BG_GC);
else {
kfree(name);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [f2fs-dev] [PATCH] f2fs: fix incorrect parsing with option string
Hi,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
> Sent: Tuesday, March 18, 2014 8:33 AM
> To: Chao Yu
> Cc: linux-f2fs-de...@lists.sourceforge.net; linux-fsde...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [f2fs-dev] [PATCH] f2fs: fix incorrect parsing with option string
>
> Hi,
>
> 2014-03-17 (월), 17:40 +0800, Chao Yu:
> > Previously 'background_gc={on***,off***}' is being parsed as correct option,
> > with this patch we cloud fix the trivial bug in mount process.
> >
> > Signed-off-by: Chao Yu
> > ---
> > fs/f2fs/super.c |4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> > index 057a3ef..6597290 100644
> > --- a/fs/f2fs/super.c
> > +++ b/fs/f2fs/super.c
> > @@ -258,9 +258,9 @@ static int parse_options(struct super_block *sb, char
> > *options)
> >
> > if (!name)
> > return -ENOMEM;
> > - if (!strncmp(name, "on", 2))
> > + if (!strncmp(name, "on", strlen(name)))
>
> What about 'background_gc=o'?
> Need to check strlen(name) == 2...
Oh, you're right. I will fix it and send v2 patch.
Thanks for your review. :)
> Thanks,
>
> > set_opt(sbi, BG_GC);
> > - else if (!strncmp(name, "off", 3))
> > + else if (!strncmp(name, "off", strlen(name)))
> > clear_opt(sbi, BG_GC);
> > else {
> > kfree(name);
>
> --
> Jaegeuk Kim
> Samsung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/2] ACPI: Default disable auto-serialization.
On Tuesday, March 18, 2014 12:31:54 AM Zheng, Lv wrote: > Hi, Rafael > > > From: Wysocki, Rafael J > > Sent: Monday, March 17, 2014 8:09 PM > > > > On 3/17/2014 5:14 AM, Lv Zheng wrote: > > > This feature enabled by the following commit is still under development. > > > > > >Commit: cd52379678785b02d7a357988cfba214fdaf92f4 > > >Subject: ACPICA: Add global option to disable method > > > auto-serialization. > > >This change adds an option to disable the auto-serialization of > > >methods that create named objects. > > > > > > This patch disables it by default temporarily according to the bug > > > reports. > > > > Well, it doesn't restore the 3.14 behavior of acpi_auto_serialize, as > > far as I can say, so we can't apply it. > > > > I still can drop the commits related to auto-serialization from my > > acpica branch. Which commits are they? > > From linux-pm/bleeding-edge branch, I found this series includes the > following commits: > > Commit: a0fd108f2da56b769472fc0095616fb370988516 > Author: Lv Zheng > Subject: ACPI: Rename kernel parameter "acpi_serialize" to > "acpi_no_auto_serialize" > > Commit: 5f1cb4a92e4c4aabd139ff9ca1e11c0e2db2ac59 > Author: Lv Zheng > Subject: ACPICA: Remove global option to serialize all control methods. > > Commit: cd52379678785b02d7a357988cfba214fdaf92f4 > Author: Bob Moore > Subject: ACPICA: Add global option to disable method auto-serialization. > > Commit: f56b05bd111b01141ef74568dc4d262c70295d03 > Author: Lv Zheng > Subject: ACPICA: Add additional named objects for the auto-serialize method > scan. > > Commit: 27f1899350a1d6baab117c03c87f0e37730047bd > Author: Bob Moore > Subject: ACPICA: Add auto-serialization support for ill-behaved control > methods. > > Reverting these commits can restore original Linux behavior. > Please check. OK, I dropped the five commits above from the acpica branch. Please check if the current ACPICA material in the bleeding-edge branch of linux-pm.git looks OK (and let me know either way). -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH 1/2] ACPICA: Dispatcher: Ignore SyncLevel for auto-serialization mechanism.
Hi, Sabrina and Valdis
Could you give this patch a try to see if this patch is working?
Thanks and best regards
-Lv
> From: Zheng, Lv
> Sent: Monday, March 17, 2014 12:15 PM
>
> From: Robert Moore
>
> It is reported that the auto-serialization mechanism has broken some
> machine. This patch fixes the issues by igoring the SyncLevel
> attribute of the marked Method.
>
> References: http://www.spinics.net/lists/linux-acpi/msg49496.html
> Reported-by: Valdis Kletnieks
> Reported-by: Sabrina Dubroka
> Signed-off-by: Bob Moore
> Signed-off-by: Lv Zheng
> ---
> drivers/acpi/acpica/acobject.h |3 ++-
> drivers/acpi/acpica/dsmethod.c | 24 +++-
> 2 files changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/acpi/acpica/acobject.h b/drivers/acpi/acpica/acobject.h
> index 1a4d618..22fb644 100644
> --- a/drivers/acpi/acpica/acobject.h
> +++ b/drivers/acpi/acpica/acobject.h
> @@ -193,7 +193,8 @@ struct acpi_object_method {
> #define ACPI_METHOD_INTERNAL_ONLY 0x02 /* Method is implemented
> internally (_OSI) */
> #define ACPI_METHOD_SERIALIZED 0x04 /* Method is serialized */
> #define ACPI_METHOD_SERIALIZED_PENDING 0x08 /* Method is to be marked
> serialized */
> -#define ACPI_METHOD_MODIFIED_NAMESPACE 0x10 /* Method modified the
> namespace */
> +#define ACPI_METHOD_IGNORE_SYNC_LEVEL 0x10 /* Method was auto-serialized
> at table load time */
> +#define ACPI_METHOD_MODIFIED_NAMESPACE 0x20 /* Method modified the
> namespace */
>
>
> /**
> *
> diff --git a/drivers/acpi/acpica/dsmethod.c b/drivers/acpi/acpica/dsmethod.c
> index 73764c7..3c7f737 100644
> --- a/drivers/acpi/acpica/dsmethod.c
> +++ b/drivers/acpi/acpica/dsmethod.c
> @@ -175,8 +175,15 @@ acpi_ds_detect_named_opcodes(struct acpi_walk_state
> *walk_state,
>* At this point, we know we have a Named object opcode.
>* Mark the method as serialized. Later code will create a mutex for
>* this method to enforce serialization.
> + *
> + * Note, ACPI_METHOD_IGNORE_SYNC_LEVEL flag means that we will ignore
> the
> + * Sync Level mechanism for this method, even though it is now
> serialized.
> + * Otherwise, there can be conflicts with existing ASL code that
> actually
> + * uses sync levels.
>*/
> - walk_state->method_desc->method.info_flags |= ACPI_METHOD_SERIALIZED;
> + walk_state->method_desc->method.sync_level = 0;
> + walk_state->method_desc->method.info_flags |=
> + (ACPI_METHOD_SERIALIZED | ACPI_METHOD_IGNORE_SYNC_LEVEL);
>
> ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> "Method serialized [%4.4s] %p - [%s] (%4.4X)\n",
> @@ -349,13 +356,19 @@ acpi_ds_begin_method_execution(struct
> acpi_namespace_node *method_node,
> /*
>* The current_sync_level (per-thread) must be less than or
> equal to
>* the sync level of the method. This mechanism provides some
> - * deadlock prevention
> + * deadlock prevention.
> + *
> + * If the method was auto-serialized, we just ignore the sync
> level
> + * mechanism, because auto-serialization of methods can
> interfere
> + * with ASL code that actually uses sync levels.
>*
>* Top-level method invocation has no walk state at this point
>*/
> if (walk_state &&
> - (walk_state->thread->current_sync_level >
> - obj_desc->method.mutex->mutex.sync_level)) {
> + (!(obj_desc->method.
> +info_flags & ACPI_METHOD_IGNORE_SYNC_LEVEL))
> + && (walk_state->thread->current_sync_level >
> + obj_desc->method.mutex->mutex.sync_level)) {
> ACPI_ERROR((AE_INFO,
> "Cannot acquire Mutex for method [%4.4s],
> current SyncLevel is too large (%u)",
> acpi_ut_get_node_name(method_node),
> @@ -800,7 +813,8 @@ acpi_ds_terminate_control_method(union
> acpi_operand_object *method_desc,
> method_desc->method.info_flags &=
> ~ACPI_METHOD_SERIALIZED_PENDING;
> method_desc->method.info_flags |=
> - ACPI_METHOD_SERIALIZED;
> + (ACPI_METHOD_SERIALIZED |
> + ACPI_METHOD_IGNORE_SYNC_LEVEL);
> method_desc->method.sync_level = 0;
> }
>
> --
> 1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/12] scsi/NCR5380: use NCR5380_dprint() instead of NCR5380_print()
Only the NCR5380_dprint() macro should invoke the NCR5380_print() function.
That's why NCR5380.c only defines the function #if NDEBUG. Use the standard
macro.
Signed-off-by: Finn Thain
---
drivers/scsi/sun3_scsi.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Index: linux-m68k/drivers/scsi/sun3_scsi.c
===
--- linux-m68k.orig/drivers/scsi/sun3_scsi.c2014-03-18 00:18:32.0
+1100
+++ linux-m68k/drivers/scsi/sun3_scsi.c 2014-03-18 00:18:33.0 +1100
@@ -79,8 +79,6 @@
#include
#include "sun3_scsi.h"
-static void NCR5380_print(struct Scsi_Host *instance);
-
/* #define OLDDMA */
#define USE_WRAPPER
@@ -463,7 +461,7 @@ static unsigned long sun3scsi_dma_setup(
printk("scsi%d: fifo_mismatch %04x not %04x\n",
default_instance->host_no, dregs->fifo_count,
(unsigned int) count);
- NCR5380_print(default_instance);
+ NCR5380_dprint(NDEBUG_DMA, default_instance);
}
/* setup udc */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/12] scsi/NCR5380: remove redundant HOSTS_C macro tests
HOSTS_C is always undefined. There is no hosts.c anymore.
Signed-off-by: Finn Thain
---
drivers/scsi/g_NCR5380.h |3 ---
drivers/scsi/mac_scsi.h |3 ---
drivers/scsi/pas16.h |3 ---
drivers/scsi/sun3_scsi.h |3 ---
drivers/scsi/t128.h |3 ---
5 files changed, 15 deletions(-)
Index: linux-m68k/drivers/scsi/g_NCR5380.h
===
--- linux-m68k.orig/drivers/scsi/g_NCR5380.h2014-03-17 23:49:30.0
+1100
+++ linux-m68k/drivers/scsi/g_NCR5380.h 2014-03-18 00:18:30.0 +1100
@@ -58,8 +58,6 @@ static const char* generic_NCR5380_info(
#define CAN_QUEUE 16
#endif
-#ifndef HOSTS_C
-
#define __STRVAL(x) #x
#define STRVAL(x) __STRVAL(x)
@@ -131,7 +129,6 @@ static const char* generic_NCR5380_info(
#define BOARD_NCR53C400A 2
#define BOARD_DTC3181E 3
-#endif /* else def HOSTS_C */
#endif /* ndef ASM */
#endif /* GENERIC_NCR5380_H */
Index: linux-m68k/drivers/scsi/mac_scsi.h
===
--- linux-m68k.orig/drivers/scsi/mac_scsi.h 2014-03-18 00:18:20.0
+1100
+++ linux-m68k/drivers/scsi/mac_scsi.h 2014-03-18 00:18:30.0 +1100
@@ -51,8 +51,6 @@
#include
-#ifndef HOSTS_C
-
#define NCR5380_implementation_fields \
int port, ctrl
@@ -75,7 +73,6 @@
#define NCR5380_show_info macscsi_show_info
#define NCR5380_write_info macscsi_write_info
-#endif /* ndef HOSTS_C */
#endif /* ndef ASM */
#endif /* MAC_NCR5380_H */
Index: linux-m68k/drivers/scsi/pas16.h
===
--- linux-m68k.orig/drivers/scsi/pas16.h2014-03-17 23:49:30.0
+1100
+++ linux-m68k/drivers/scsi/pas16.h 2014-03-18 00:18:30.0 +1100
@@ -129,8 +129,6 @@ static int pas16_bus_reset(Scsi_Cmnd *);
#define CAN_QUEUE 32
#endif
-#ifndef HOSTS_C
-
#define NCR5380_implementation_fields \
volatile unsigned short io_port
@@ -171,6 +169,5 @@ static int pas16_bus_reset(Scsi_Cmnd *);
#define PAS16_IRQS 0xd4a8
-#endif /* else def HOSTS_C */
#endif /* ndef ASM */
#endif /* PAS16_H */
Index: linux-m68k/drivers/scsi/sun3_scsi.h
===
--- linux-m68k.orig/drivers/scsi/sun3_scsi.h2014-03-18 00:18:20.0
+1100
+++ linux-m68k/drivers/scsi/sun3_scsi.h 2014-03-18 00:18:30.0 +1100
@@ -82,8 +82,6 @@ static int sun3scsi_release (struct Scsi
#define SUN3_SCSI_NAME "Sun3 NCR5380 SCSI"
#endif
-#ifndef HOSTS_C
-
#define NCR5380_implementation_fields \
int port, ctrl
@@ -371,6 +369,5 @@ struct sun3_udc_regs {
-#endif /* ndef HOSTS_C */
#endif /* SUN3_NCR5380_H */
Index: linux-m68k/drivers/scsi/t128.h
===
--- linux-m68k.orig/drivers/scsi/t128.h 2014-03-17 23:49:30.0 +1100
+++ linux-m68k/drivers/scsi/t128.h 2014-03-18 00:18:30.0 +1100
@@ -107,8 +107,6 @@ static int t128_bus_reset(struct scsi_cm
#define CAN_QUEUE 32
#endif
-#ifndef HOSTS_C
-
#define NCR5380_implementation_fields \
void __iomem *base
@@ -148,6 +146,5 @@ static int t128_bus_reset(struct scsi_cm
#define T128_IRQS 0xc4a8
-#endif /* else def HOSTS_C */
#endif /* ndef ASM */
#endif /* T128_H */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/12] scsi/NCR5380: remove old CVS keywords
Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c |2 -- drivers/scsi/NCR5380.h |4 drivers/scsi/g_NCR5380.c |4 drivers/scsi/g_NCR5380.h |4 drivers/scsi/mac_scsi.c |4 drivers/scsi/mac_scsi.h |4 drivers/scsi/sun3_scsi.c |4 drivers/scsi/sun3_scsi.h |4 drivers/scsi/t128.c |4 drivers/scsi/t128.h |4 10 files changed, 38 deletions(-) Index: linux-m68k/drivers/scsi/NCR5380.c === --- linux-m68k.orig/drivers/scsi/NCR5380.c 2014-03-17 23:49:28.0 +1100 +++ linux-m68k/drivers/scsi/NCR5380.c 2014-03-18 00:18:32.0 +1100 @@ -27,8 +27,6 @@ */ /* - * $Log: NCR5380.c,v $ - * Revision 1.10 1998/9/2 Alan Cox * (a...@lxorguk.ukuu.org.uk) * Fixed up the timer lockups reported so far. Things still suck. Looking Index: linux-m68k/drivers/scsi/NCR5380.h === --- linux-m68k.orig/drivers/scsi/NCR5380.h 2014-03-17 23:49:28.0 +1100 +++ linux-m68k/drivers/scsi/NCR5380.h 2014-03-18 00:18:32.0 +1100 @@ -21,10 +21,6 @@ * 1+ (800) 334-5454 */ -/* - * $Log: NCR5380.h,v $ - */ - #ifndef NCR5380_H #define NCR5380_H Index: linux-m68k/drivers/scsi/g_NCR5380.c === --- linux-m68k.orig/drivers/scsi/g_NCR5380.c2014-03-17 23:49:28.0 +1100 +++ linux-m68k/drivers/scsi/g_NCR5380.c 2014-03-18 00:18:32.0 +1100 @@ -78,10 +78,6 @@ * */ -/* - * $Log: generic_NCR5380.c,v $ - */ - /* settings for DTC3181E card with only Mustek scanner attached */ #define USLEEP #define USLEEP_POLL1 Index: linux-m68k/drivers/scsi/g_NCR5380.h === --- linux-m68k.orig/drivers/scsi/g_NCR5380.h2014-03-18 00:18:30.0 +1100 +++ linux-m68k/drivers/scsi/g_NCR5380.h 2014-03-18 00:18:32.0 +1100 @@ -25,10 +25,6 @@ * 1+ (800) 334-5454 */ -/* - * $Log: generic_NCR5380.h,v $ - */ - #ifndef GENERIC_NCR5380_H #define GENERIC_NCR5380_H Index: linux-m68k/drivers/scsi/mac_scsi.c === --- linux-m68k.orig/drivers/scsi/mac_scsi.c 2014-03-17 23:49:28.0 +1100 +++ linux-m68k/drivers/scsi/mac_scsi.c 2014-03-18 00:18:32.0 +1100 @@ -25,10 +25,6 @@ * 1+ (800) 334-5454 */ -/* - * $Log: mac_NCR5380.c,v $ - */ - #include #include #include Index: linux-m68k/drivers/scsi/mac_scsi.h === --- linux-m68k.orig/drivers/scsi/mac_scsi.h 2014-03-18 00:18:30.0 +1100 +++ linux-m68k/drivers/scsi/mac_scsi.h 2014-03-18 00:18:32.0 +1100 @@ -22,10 +22,6 @@ * 1+ (800) 334-5454 */ -/* - * $Log: cumana_NCR5380.h,v $ - */ - #ifndef MAC_NCR5380_H #define MAC_NCR5380_H Index: linux-m68k/drivers/scsi/sun3_scsi.c === --- linux-m68k.orig/drivers/scsi/sun3_scsi.c2014-03-17 23:49:28.0 +1100 +++ linux-m68k/drivers/scsi/sun3_scsi.c 2014-03-18 00:18:32.0 +1100 @@ -45,10 +45,6 @@ * USLEEP - enable support for devices that don't disconnect. Untested. */ -/* - * $Log: sun3_NCR5380.c,v $ - */ - #define AUTOSENSE #include Index: linux-m68k/drivers/scsi/sun3_scsi.h === --- linux-m68k.orig/drivers/scsi/sun3_scsi.h2014-03-18 00:18:30.0 +1100 +++ linux-m68k/drivers/scsi/sun3_scsi.h 2014-03-18 00:18:32.0 +1100 @@ -29,10 +29,6 @@ * 1+ (800) 334-5454 */ -/* - * $Log: cumana_NCR5380.h,v $ - */ - #ifndef SUN3_NCR5380_H #define SUN3_NCR5380_H Index: linux-m68k/drivers/scsi/t128.c === --- linux-m68k.orig/drivers/scsi/t128.c 2014-03-17 23:49:28.0 +1100 +++ linux-m68k/drivers/scsi/t128.c 2014-03-18 00:18:32.0 +1100 @@ -102,10 +102,6 @@ * 15 9-11 */ -/* - * $Log: t128.c,v $ - */ - #include #include #include Index: linux-m68k/drivers/scsi/t128.h === --- linux-m68k.orig/drivers/scsi/t128.h 2014-03-18 00:18:30.0 +1100 +++ linux-m68k/drivers/scsi/t128.h 2014-03-18 00:18:32.0 +1100 @@ -34,10 +34,6 @@ * 1+ (800) 334-5454 */ -/* - * $Log: t128.h,v $ - */ - #ifndef T128_H #define T128_H -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] staging: cxt1e1: remove unneeded mkret() calls
The mkret() change a value of error from positive to
negative. This patch is modified to return negative value
when it failed. It doesn't need to call with function
for changing from positive to negative.
Signed-off-by: Daeseok Youn
---
v2: fix a typo in subject
this patch is rebased in staging-next branch.
drivers/staging/cxt1e1/linux.c | 72 +--
drivers/staging/cxt1e1/musycc.c|2 +-
drivers/staging/cxt1e1/pmcc4_drv.c | 30 --
3 files changed, 45 insertions(+), 59 deletions(-)
diff --git a/drivers/staging/cxt1e1/linux.c b/drivers/staging/cxt1e1/linux.c
index 58fe0fe..9005d55 100644
--- a/drivers/staging/cxt1e1/linux.c
+++ b/drivers/staging/cxt1e1/linux.c
@@ -145,16 +145,6 @@ get_hdlc_name(hdlc_device *hdlc)
return dev->name;
}
-
-static status_t
-mkret(int bsd)
-{
- if (bsd > 0)
- return -bsd;
- else
- return bsd;
-}
-
/***/
#include
@@ -290,8 +280,8 @@ chan_open(struct net_device *ndev)
}
ret = c4_chan_up(priv->ci, priv->channum);
- if (ret)
- return -ret;
+ if (ret < 0)
+ return ret;
try_module_get(THIS_MODULE);
netif_start_queue(ndev);
return 0; /* no error = success */
@@ -521,8 +511,8 @@ do_get_port(struct net_device *ndev, void *data)
if (!ci)
return -EINVAL; /* get card info */
- ret = mkret(c4_get_port(ci, pp.portnum));
- if (ret)
+ ret = c4_get_port(ci, pp.portnum);
+ if (ret < 0)
return ret;
if (copy_to_user(data, >port[pp.portnum].p,
sizeof(struct sbecom_port_param)))
@@ -549,7 +539,7 @@ do_set_port(struct net_device *ndev, void *data)
return -ENXIO;
memcpy(>port[pp.portnum].p, , sizeof(struct sbecom_port_param));
- return mkret(c4_set_port(ci, pp.portnum));
+ return c4_set_port(ci, pp.portnum);
}
/* work the port loopback mode as per directed */
@@ -564,7 +554,7 @@ do_port_loop(struct net_device *ndev, void *data)
ci = get_ci_by_dev(ndev);
if (!ci)
return -EINVAL;
- return mkret(c4_loop_port(ci, pp.portnum, pp.port_mode));
+ return c4_loop_port(ci, pp.portnum, pp.port_mode);
}
/* set the specified register with the given value / or just read it */
@@ -580,8 +570,8 @@ do_framer_rw(struct net_device *ndev, void *data)
ci = get_ci_by_dev(ndev);
if (!ci)
return -EINVAL;
- ret = mkret(c4_frame_rw(ci, ));
- if (ret)
+ ret = c4_frame_rw(ci, );
+ if (ret < 0)
return ret;
if (copy_to_user(data, , sizeof(struct sbecom_port_param)))
return -EFAULT;
@@ -601,7 +591,8 @@ do_pld_rw(struct net_device *ndev, void *data)
ci = get_ci_by_dev(ndev);
if (!ci)
return -EINVAL;
- ret = mkret(c4_pld_rw(ci, ));
+
+ ret = c4_pld_rw(ci, );
if (ret)
return ret;
if (copy_to_user(data, , sizeof(struct sbecom_port_param)))
@@ -622,8 +613,8 @@ do_musycc_rw(struct net_device *ndev, void *data)
ci = get_ci_by_dev(ndev);
if (!ci)
return -EINVAL;
- ret = mkret(c4_musycc_rw(ci, ));
- if (ret)
+ ret = c4_musycc_rw(ci, );
+ if (ret < 0)
return ret;
if (copy_to_user(data, , sizeof(struct c4_musycc_param)))
return -EFAULT;
@@ -640,8 +631,8 @@ do_get_chan(struct net_device *ndev, void *data)
sizeof(struct sbecom_chan_param)))
return -EFAULT;
- ret = mkret(c4_get_chan(cp.channum, ));
- if (ret)
+ ret = c4_get_chan(cp.channum, );
+ if (ret < 0)
return ret;
if (copy_to_user(data, , sizeof(struct sbecom_chan_param)))
@@ -653,7 +644,6 @@ static status_t
do_set_chan(struct net_device *ndev, void *data)
{
struct sbecom_chan_param cp;
- int ret;
ci_t *ci;
if (copy_from_user(, data, sizeof(struct sbecom_chan_param)))
@@ -661,13 +651,7 @@ do_set_chan(struct net_device *ndev, void *data)
ci = get_ci_by_dev(ndev);
if (!ci)
return -EINVAL;
- switch (ret = mkret(c4_set_chan(cp.channum, )))
- {
- case 0:
- return 0;
- default:
- return ret;
- }
+ return c4_set_chan(cp.channum, );
}
static status_t
@@ -686,8 +670,8 @@ do_create_chan(struct net_device *ndev, void *data)
dev = create_chan(ndev, ci, );
if (!dev)
return -EBUSY;
- ret = mkret(c4_new_chan(ci, cp.port, cp.channum, dev));
- if (ret) {
+ ret = c4_new_chan(ci, cp.port, cp.channum, dev);
+ if (ret < 0) {
/* needed due to
Re: [PATCH 2/2] net: cdc_ncm: respect operator preferred MTU reported by MBIM
On Mon, Mar 17, 2014 at 2:27 PM, Bjørn Mork wrote: > > This sounds all reasonable to me. Thanks for taking the time to explain > it in such detail. I did know that some vendors set wMaxSegmentSize too > low, but had no idea that vendors were using the extended descriptor > instead of MBIM_CID_IP_CONFIGURATION. > > If so, then yes, it does make sense for the driver to base the default > MTU on this descriptor. Hopefully, subsequent MBIM specifications would further clarify and simplify things a bit, but it's gonna be a slow process as we all know :-/ > >>> wMTU access needs le16_to_cpu. >> >> Good catch. I will fix it in patch v2. > > Tip: I found this because my test script/makefile includes > "C=1 CF=-D__CHECK_ENDIAN__" > > I find that very useful when dealing with USB on a little endian system, > like most of us have. It's all too easy to miss a conversion otherwise. > Thanks again for the review and tip. I've submitted patch v2 to address the le16_to_cpu conversion. >>> Could we move this final MTU correction from cdc_ncm_setup to >>> cdc_ncm_bind_common to avoid bloating the device struct with another >>> descriptor pointer we donæt really need to keep around? >>> >>> I know we look into descriptors in cdc_ncm_setup, because we have to, >>> but ideally I would have loved to see cdc_ncm_setup dealing with *just* >>> the NCM/MBIM specific control setup messages and cdc_ncm_bind_common >>> dealing with all the functional descriptors. That seems most logic to >>> me (but is of course only my personal opinion and nothing else - I do >>> not know what the original cdc_ncm author intended) >>> >> >> I understand the argument against the extra descriptor pointer. But I >> think it's better to keep the mtu related code together so that one >> can easily see how MTU is determined when trying to change or refactor >> the code. I haven't looked into what cdc_ncm_setup was originally >> intended for. If we'd like to avoid adding an extra pointer in >> cdc_ncm_ctx, we could have cdc_ncm_bind passing a locally scoped >> context to cdc_ncm_setup. > > No, the extra pointer doesn't matter much. Just keep it as it is. > > > Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/12] scsi/NCR5380: fix dprintk macro usage and definition
There are three implementations of the core NCR5380 driver and three sets
of debugging macro definitions. And all three implementations use the
NCR5380.h header as well.
Two of the definitions of the dprintk macro accept a variable argument list
whereas the third does not. Standardize on the variable argument list.
Signed-off-by: Finn Thain
---
drivers/scsi/NCR5380.c | 126 -
drivers/scsi/NCR5380.h |6 +-
2 files changed, 66 insertions(+), 66 deletions(-)
Index: linux-m68k/drivers/scsi/NCR5380.c
===
--- linux-m68k.orig/drivers/scsi/NCR5380.c 2014-03-18 00:18:34.0
+1100
+++ linux-m68k/drivers/scsi/NCR5380.c 2014-03-18 00:18:34.0 +1100
@@ -1003,7 +1003,7 @@ static int NCR5380_queue_command_lck(Scs
LIST(cmd, tmp);
tmp->host_scribble = (unsigned char *) cmd;
}
- dprintk(NDEBUG_QUEUES, ("scsi%d : command added to %s of queue\n",
instance->host_no, (cmd->cmnd[0] == REQUEST_SENSE) ? "head" : "tail"));
+ dprintk(NDEBUG_QUEUES, "scsi%d : command added to %s of queue\n",
instance->host_no, (cmd->cmnd[0] == REQUEST_SENSE) ? "head" : "tail");
/* Run the coroutine if it isn't already running. */
/* Kick off command processing */
@@ -1038,7 +1038,7 @@ static void NCR5380_main(struct work_str
/* Lock held here */
done = 1;
if (!hostdata->connected && !hostdata->selecting) {
- dprintk(NDEBUG_MAIN, ("scsi%d : not connected\n",
instance->host_no));
+ dprintk(NDEBUG_MAIN, "scsi%d : not connected\n",
instance->host_no);
/*
* Search through the issue_queue for a command destined
* for a target that's not busy.
@@ -1046,7 +1046,7 @@ static void NCR5380_main(struct work_str
for (tmp = (Scsi_Cmnd *) hostdata->issue_queue, prev =
NULL; tmp; prev = tmp, tmp = (Scsi_Cmnd *) tmp->host_scribble)
{
if (prev != tmp)
- dprintk(NDEBUG_LISTS, ("MAIN tmp=%p
target=%d busy=%d lun=%d\n", tmp, tmp->device->id,
hostdata->busy[tmp->device->id], tmp->device->lun));
+ dprintk(NDEBUG_LISTS, "MAIN tmp=%p
target=%d busy=%d lun=%d\n", tmp, tmp->device->id,
hostdata->busy[tmp->device->id], tmp->device->lun);
/* When we find one, remove it from the issue
queue. */
if (!(hostdata->busy[tmp->device->id] & (1 <<
tmp->device->lun))) {
if (prev) {
@@ -1064,7 +1064,7 @@ static void NCR5380_main(struct work_str
* On failure, we must add the command
back to the
* issue queue so we can keep trying.
*/
- dprintk(NDEBUG_MAIN|NDEBUG_QUEUES,
("scsi%d : main() : command for target %d lun %d removed from issue_queue\n",
instance->host_no, tmp->device->id, tmp->device->lun));
+ dprintk(NDEBUG_MAIN|NDEBUG_QUEUES,
"scsi%d : main() : command for target %d lun %d removed from issue_queue\n",
instance->host_no, tmp->device->id, tmp->device->lun);
/*
* A successful selection is defined as
one that
@@ -1093,7 +1093,7 @@ static void NCR5380_main(struct work_str
tmp->host_scribble = (unsigned
char *) hostdata->issue_queue;
hostdata->issue_queue = tmp;
done = 0;
-
dprintk(NDEBUG_MAIN|NDEBUG_QUEUES, ("scsi%d : main(): select() failed, returned
to issue_queue\n", instance->host_no));
+
dprintk(NDEBUG_MAIN|NDEBUG_QUEUES, "scsi%d : main(): select() failed, returned
to issue_queue\n", instance->host_no);
}
/* lock held here still */
} /* if target/lun is not busy */
@@ -1123,9 +1123,9 @@ static void NCR5380_main(struct work_str
#endif
&& (!hostdata->time_expires ||
time_before_eq(hostdata->time_expires, jiffies))
) {
- dprintk(NDEBUG_MAIN, ("scsi%d : main() : performing
information transfer\n", instance->host_no));
+ dprintk(NDEBUG_MAIN, "scsi%d : main() : performing
information transfer\n", instance->host_no);
NCR5380_information_transfer(instance);
-
[PATCH 08/12] scsi/NCR5380: adopt dprintk()
All NCR5380 drivers already include the NCR5380.h header. Better to
adopt those macros rather than have three variations on them.
Moreover, the macros in NCR5380.h are preferable because the atari_NCR5380
and sun3_NCR5380 versions are inflexible. For example, they can't accomodate
dprintk(NDEBUG_MAIN | NDEBUG_QUEUES, ...)
Replace the *_PRINTK macros from atari_NCR5380.h and sun3_NCR5380.h with
the equivalent macros from NCR5380.h.
Signed-off-by: Finn Thain
---
drivers/scsi/atari_NCR5380.c | 130 +--
drivers/scsi/atari_scsi.c| 16 ++---
drivers/scsi/sun3_NCR5380.c | 122
3 files changed, 134 insertions(+), 134 deletions(-)
Index: linux-m68k/drivers/scsi/atari_NCR5380.c
===
--- linux-m68k.orig/drivers/scsi/atari_NCR5380.c2014-03-18
00:18:35.0 +1100
+++ linux-m68k/drivers/scsi/atari_NCR5380.c 2014-03-18 00:18:36.0
+1100
@@ -370,7 +370,7 @@ static int is_lun_busy(Scsi_Cmnd *cmd, i
return 0;
if (TagAlloc[cmd->device->id][cmd->device->lun].nr_allocated >=
TagAlloc[cmd->device->id][cmd->device->lun].queue_size) {
- TAG_PRINTK("scsi%d: target %d lun %d: no free tags\n",
+ dprintk(NDEBUG_TAGS, "scsi%d: target %d lun %d: no free tags\n",
H_NO(cmd), cmd->device->id, cmd->device->lun);
return 1;
}
@@ -394,7 +394,7 @@ static void cmd_get_tag(Scsi_Cmnd *cmd,
!setup_use_tagged_queuing || !cmd->device->tagged_supported) {
cmd->tag = TAG_NONE;
hostdata->busy[cmd->device->id] |= (1 << cmd->device->lun);
- TAG_PRINTK("scsi%d: target %d lun %d now allocated by untagged "
+ dprintk(NDEBUG_TAGS, "scsi%d: target %d lun %d now allocated by
untagged "
"command\n", H_NO(cmd), cmd->device->id,
cmd->device->lun);
} else {
TAG_ALLOC *ta = [cmd->device->id][cmd->device->lun];
@@ -402,7 +402,7 @@ static void cmd_get_tag(Scsi_Cmnd *cmd,
cmd->tag = find_first_zero_bit(ta->allocated, MAX_TAGS);
set_bit(cmd->tag, ta->allocated);
ta->nr_allocated++;
- TAG_PRINTK("scsi%d: using tag %d for target %d lun %d "
+ dprintk(NDEBUG_TAGS, "scsi%d: using tag %d for target %d lun %d
"
"(now %d tags in use)\n",
H_NO(cmd), cmd->tag, cmd->device->id,
cmd->device->lun, ta->nr_allocated);
@@ -420,7 +420,7 @@ static void cmd_free_tag(Scsi_Cmnd *cmd)
if (cmd->tag == TAG_NONE) {
hostdata->busy[cmd->device->id] &= ~(1 << cmd->device->lun);
- TAG_PRINTK("scsi%d: target %d lun %d untagged cmd finished\n",
+ dprintk(NDEBUG_TAGS, "scsi%d: target %d lun %d untagged cmd
finished\n",
H_NO(cmd), cmd->device->id, cmd->device->lun);
} else if (cmd->tag >= MAX_TAGS) {
printk(KERN_NOTICE "scsi%d: trying to free bad tag %d!\n",
@@ -429,7 +429,7 @@ static void cmd_free_tag(Scsi_Cmnd *cmd)
TAG_ALLOC *ta = [cmd->device->id][cmd->device->lun];
clear_bit(cmd->tag, ta->allocated);
ta->nr_allocated--;
- TAG_PRINTK("scsi%d: freed tag %d for target %d lun %d\n",
+ dprintk(NDEBUG_TAGS, "scsi%d: freed tag %d for target %d lun
%d\n",
H_NO(cmd), cmd->tag, cmd->device->id,
cmd->device->lun);
}
}
@@ -478,7 +478,7 @@ static void merge_contiguous_buffers(Scs
for (endaddr = virt_to_phys(cmd->SCp.ptr + cmd->SCp.this_residual - 1)
+ 1;
cmd->SCp.buffers_residual &&
virt_to_phys(sg_virt(>SCp.buffer[1])) == endaddr;) {
- MER_PRINTK("VTOP(%p) == %08lx -> merging\n",
+ dprintk(NDEBUG_MERGING, "VTOP(%p) == %08lx -> merging\n",
page_address(sg_page(>SCp.buffer[1])), endaddr);
#if (NDEBUG & NDEBUG_MERGING)
++cnt;
@@ -490,7 +490,7 @@ static void merge_contiguous_buffers(Scs
}
#if (NDEBUG & NDEBUG_MERGING)
if (oldlen != cmd->SCp.this_residual)
- MER_PRINTK("merged %d buffers from %p, new length %08x\n",
+ dprintk(NDEBUG_MERGING, "merged %d buffers from %p, new length
%08x\n",
cnt, cmd->SCp.ptr, cmd->SCp.this_residual);
#endif
}
@@ -676,7 +676,7 @@ static inline void NCR5380_all_init(void
{
static int done = 0;
if (!done) {
- INI_PRINTK("scsi : NCR5380_all_init()\n");
+ dprintk(NDEBUG_INIT, "scsi : NCR5380_all_init()\n");
done = 1;
}
}
@@ -984,7 +984,7 @@ static int NCR5380_queue_command_lck(Scs
}
local_irq_restore(flags);
-
[PATCH 10/12] scsi/NCR5380: remove unused macro definitions
Remove the unused (and divergent) debugging macro definitions from
the sun3_NCR5380 and atari_NCR5380 drivers. These drivers have been
converted to use the common macros in NCR5380.h.
Signed-off-by: Finn Thain
---
drivers/scsi/atari_scsi.h | 93 ---
drivers/scsi/sun3_scsi.h | 181 --
2 files changed, 274 deletions(-)
Index: linux-m68k/drivers/scsi/atari_scsi.h
===
--- linux-m68k.orig/drivers/scsi/atari_scsi.h 2014-03-17 23:49:22.0
+1100
+++ linux-m68k/drivers/scsi/atari_scsi.h2014-03-18 00:18:37.0
+1100
@@ -80,99 +80,6 @@
#define SCSI_RESET_HOST_RESET 0x200
#define SCSI_RESET_ACTION 0xff
-/* Debugging printk definitions:
- *
- * ARB -> arbitration
- * ASEN -> auto-sense
- * DMA -> DMA
- * HSH -> PIO handshake
- * INF -> information transfer
- * INI -> initialization
- * INT -> interrupt
- * LNK -> linked commands
- * MAIN -> NCR5380_main() control flow
- * NDAT -> no data-out phase
- * NWR -> no write commands
- * PIO -> PIO transfers
- * PDMA -> pseudo DMA (unused on Atari)
- * QU -> queues
- * RSL -> reselections
- * SEL -> selections
- * USL -> usleep cpde (unused on Atari)
- * LBS -> last byte sent (unused on Atari)
- * RSS -> restarting of selections
- * EXT -> extended messages
- * ABRT -> aborting and resetting
- * TAG -> queue tag handling
- * MER -> merging of consec. buffers
- *
- */
-
-#define dprint(flg, format...) \
-({ \
- if (NDEBUG & (flg)) \
- printk(KERN_DEBUG format); \
-})
-
-#define ARB_PRINTK(format, args...) \
- dprint(NDEBUG_ARBITRATION, format , ## args)
-#define ASEN_PRINTK(format, args...) \
- dprint(NDEBUG_AUTOSENSE, format , ## args)
-#define DMA_PRINTK(format, args...) \
- dprint(NDEBUG_DMA, format , ## args)
-#define HSH_PRINTK(format, args...) \
- dprint(NDEBUG_HANDSHAKE, format , ## args)
-#define INF_PRINTK(format, args...) \
- dprint(NDEBUG_INFORMATION, format , ## args)
-#define INI_PRINTK(format, args...) \
- dprint(NDEBUG_INIT, format , ## args)
-#define INT_PRINTK(format, args...) \
- dprint(NDEBUG_INTR, format , ## args)
-#define LNK_PRINTK(format, args...) \
- dprint(NDEBUG_LINKED, format , ## args)
-#define MAIN_PRINTK(format, args...) \
- dprint(NDEBUG_MAIN, format , ## args)
-#define NDAT_PRINTK(format, args...) \
- dprint(NDEBUG_NO_DATAOUT, format , ## args)
-#define NWR_PRINTK(format, args...) \
- dprint(NDEBUG_NO_WRITE, format , ## args)
-#define PIO_PRINTK(format, args...) \
- dprint(NDEBUG_PIO, format , ## args)
-#define PDMA_PRINTK(format, args...) \
- dprint(NDEBUG_PSEUDO_DMA, format , ## args)
-#define QU_PRINTK(format, args...) \
- dprint(NDEBUG_QUEUES, format , ## args)
-#define RSL_PRINTK(format, args...) \
- dprint(NDEBUG_RESELECTION, format , ## args)
-#define SEL_PRINTK(format, args...) \
- dprint(NDEBUG_SELECTION, format , ## args)
-#define USL_PRINTK(format, args...) \
- dprint(NDEBUG_USLEEP, format , ## args)
-#define LBS_PRINTK(format, args...) \
- dprint(NDEBUG_LAST_BYTE_SENT, format , ## args)
-#define RSS_PRINTK(format, args...) \
- dprint(NDEBUG_RESTART_SELECT, format , ## args)
-#define EXT_PRINTK(format, args...) \
- dprint(NDEBUG_EXTENDED, format , ## args)
-#define ABRT_PRINTK(format, args...) \
- dprint(NDEBUG_ABORT, format , ## args)
-#define TAG_PRINTK(format, args...) \
- dprint(NDEBUG_TAGS, format , ## args)
-#define MER_PRINTK(format, args...) \
- dprint(NDEBUG_MERGING, format , ## args)
-
-/* conditional macros for NCR5380_print_{,phase,status} */
-
-#define NCR_PRINT(mask)\
- ((NDEBUG & (mask)) ? NCR5380_print(instance) : (void)0)
-
-#define NCR_PRINT_PHASE(mask) \
- ((NDEBUG & (mask)) ? NCR5380_print_phase(instance) : (void)0)
-
-#define NCR_PRINT_STATUS(mask) \
- ((NDEBUG & (mask)) ? NCR5380_print_status(instance) : (void)0)
-
-
#endif /* ndef ASM */
#endif /* ATARI_SCSI_H */
Index: linux-m68k/drivers/scsi/sun3_scsi.h
===
--- linux-m68k.orig/drivers/scsi/sun3_scsi.h2014-03-18 00:18:32.0
+1100
+++ linux-m68k/drivers/scsi/sun3_scsi.h 2014-03-18 00:18:37.0 +1100
@@ -182,188 +182,7 @@ struct sun3_udc_regs {
#define VME_DATA24 0x3d00
-// debugging printk's, taken from atari_scsi.h
-/* Debugging printk definitions:
- *
- * ARB -> arbitration
- * ASEN -> auto-sense
- * DMA -> DMA
- * HSH -> PIO handshake
- * INF -> information transfer
- * INI -> initialization
- * INT -> interrupt
- * LNK -> linked commands
- * MAIN -> NCR5380_main() control flow
- * NDAT -> no data-out phase
- * NWR -> no write commands
- * PIO -> PIO transfers
- * PDMA ->
[PATCH 07/12] scsi/NCR5380: adopt NCR5380_dprint() and NCR5380_dprint_phase()
All NCR5380 drivers already include the NCR5380.h header. Better to
adopt those macros rather than have three variations on them.
Moreover, the macros in NCR5380.h are preferable anyway: the atari_NCR5380
and sun3_NCR5380 versions are inflexible. For example, they can't accomodate
NCR5380_dprint(NDEBUG_MAIN | NDEBUG_QUEUES, ...)
Replace the NCR_PRINT* macros from atari_NCR5380.h and sun3_NCR5380.h with
the equivalent macros from NCR5380.h.
Signed-off-by: Finn Thain
---
drivers/scsi/atari_NCR5380.c | 22 +++---
drivers/scsi/sun3_NCR5380.c | 22 +++---
2 files changed, 22 insertions(+), 22 deletions(-)
Index: linux-m68k/drivers/scsi/atari_NCR5380.c
===
--- linux-m68k.orig/drivers/scsi/atari_NCR5380.c2014-03-17
23:49:25.0 +1100
+++ linux-m68k/drivers/scsi/atari_NCR5380.c 2014-03-18 00:18:35.0
+1100
@@ -739,8 +739,8 @@ static void NCR5380_print_status(struct
Scsi_Cmnd *ptr;
unsigned long flags;
- NCR_PRINT(NDEBUG_ANY);
- NCR_PRINT_PHASE(NDEBUG_ANY);
+ NCR5380_dprint(NDEBUG_ANY, instance);
+ NCR5380_dprint_phase(NDEBUG_ANY, instance);
hostdata = (struct NCR5380_hostdata *)instance->hostdata;
@@ -1268,7 +1268,7 @@ static irqreturn_t NCR5380_intr(int irq,
INT_PRINTK("scsi%d: BASR=%02x\n", HOSTNO, basr);
/* dispatch to appropriate routine if found and done=0 */
if (basr & BASR_IRQ) {
- NCR_PRINT(NDEBUG_INTR);
+ NCR5380_dprint(NDEBUG_INTR, instance);
if ((NCR5380_read(STATUS_REG) & (SR_SEL|SR_IO)) ==
(SR_SEL|SR_IO)) {
done = 0;
ENABLE_IRQ();
@@ -1396,7 +1396,7 @@ static int NCR5380_select(struct Scsi_Ho
unsigned long flags;
hostdata->restart_select = 0;
- NCR_PRINT(NDEBUG_ARBITRATION);
+ NCR5380_dprint(NDEBUG_ARBITRATION, instance);
ARB_PRINTK("scsi%d: starting arbitration, id = %d\n", HOSTNO,
instance->this_id);
@@ -1617,7 +1617,7 @@ static int NCR5380_select(struct Scsi_Ho
printk(KERN_ERR "scsi%d: weirdness\n", HOSTNO);
if (hostdata->restart_select)
printk(KERN_NOTICE "\trestart select\n");
- NCR_PRINT(NDEBUG_ANY);
+ NCR5380_dprint(NDEBUG_ANY, instance);
NCR5380_write(SELECT_ENABLE_REG, hostdata->id_mask);
return -1;
}
@@ -1742,7 +1742,7 @@ static int NCR5380_transfer_pio(struct S
/* Check for phase mismatch */
if ((tmp & PHASE_MASK) != p) {
PIO_PRINTK("scsi%d: phase mismatch\n", HOSTNO);
- NCR_PRINT_PHASE(NDEBUG_PIO);
+ NCR5380_dprint_phase(NDEBUG_PIO, instance);
break;
}
@@ -1764,18 +1764,18 @@ static int NCR5380_transfer_pio(struct S
if (!(p & SR_IO)) {
if (!((p & SR_MSG) && c > 1)) {
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE |
ICR_ASSERT_DATA);
- NCR_PRINT(NDEBUG_PIO);
+ NCR5380_dprint(NDEBUG_PIO, instance);
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE |
ICR_ASSERT_DATA | ICR_ASSERT_ACK);
} else {
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE |
ICR_ASSERT_DATA | ICR_ASSERT_ATN);
- NCR_PRINT(NDEBUG_PIO);
+ NCR5380_dprint(NDEBUG_PIO, instance);
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE |
ICR_ASSERT_DATA | ICR_ASSERT_ATN
| ICR_ASSERT_ACK);
}
} else {
- NCR_PRINT(NDEBUG_PIO);
+ NCR5380_dprint(NDEBUG_PIO, instance);
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE |
ICR_ASSERT_ACK);
}
@@ -1997,7 +1997,7 @@ static void NCR5380_information_transfer
phase = (tmp & PHASE_MASK);
if (phase != old_phase) {
old_phase = phase;
- NCR_PRINT_PHASE(NDEBUG_INFORMATION);
+ NCR5380_dprint_phase(NDEBUG_INFORMATION,
instance);
}
if (sink && (phase != PHASE_MSGOUT)) {
@@ -2451,7 +2451,7 @@ static void NCR5380_information_transfer
break;
default:
printk("scsi%d: unknown phase\n", HOSTNO);
-
[PATCH 12/12] scsi/NCR5380: merge sun3_scsi_vme.c into sun3_scsi.c
The sun3 drivers suffer from a whole bunch of duplicated code. Fix this
by following the g_NCR5380_mmio example. (Notionally, sun3_scsi relates to
sun3_scsi_vme in the same way that g_NCR5380 relates to g_NCR5380_mmio.)
Dead code is also removed: we now have working debug macros so
SUN3_SCSI_DEBUG is undesirable. Dead code within #ifdef OLD_DMA is also
dropped, consistent with sun3_scsi_vme.c.
Signed-off-by: Finn Thain
---
drivers/scsi/sun3_scsi.c | 222
drivers/scsi/sun3_scsi_vme.c | 583 ---
2 files changed, 171 insertions(+), 634 deletions(-)
Index: linux-m68k/drivers/scsi/sun3_scsi.c
===
--- linux-m68k.orig/drivers/scsi/sun3_scsi.c2014-03-18 00:18:38.0
+1100
+++ linux-m68k/drivers/scsi/sun3_scsi.c 2014-03-18 00:18:39.0 +1100
@@ -3,6 +3,10 @@
*
* Sun3 DMA routines added by Sam Creasey (sa...@sammy.net)
*
+ * VME support added by Sam Creasey
+ *
+ * TODO: modify this driver to support multiple Sun3 SCSI VME boards
+ *
* Adapted from mac_scsinew.c:
*/
/*
@@ -74,7 +78,7 @@
#include "sun3_scsi.h"
#include "NCR5380.h"
-/* #define OLDDMA */
+extern int sun3_map_test(unsigned long, char *);
#define USE_WRAPPER
/*#define RESET_BOOT */
@@ -90,7 +94,11 @@
/* #define SUPPORT_TAGS */
+#ifdef SUN3_SCSI_VME
+#define ENABLE_IRQ()
+#else
#defineENABLE_IRQ()enable_irq( IRQ_SUN3_SCSI );
+#endif
static irqreturn_t scsi_sun3_intr(int irq, void *dummy);
@@ -125,10 +133,9 @@ static struct scsi_cmnd *sun3_dma_setup_
static volatile unsigned char *sun3_scsi_regp;
static volatile struct sun3_dma_regs *dregs;
-#ifdef OLDDMA
-static unsigned char *dmabuf = NULL; /* dma memory buffer */
-#endif
+#ifndef SUN3_SCSI_VME
static struct sun3_udc_regs *udc_regs = NULL;
+#endif
static unsigned char *sun3_dma_orig_addr = NULL;
static unsigned long sun3_dma_orig_count = 0;
static int sun3_dma_active = 0;
@@ -148,6 +155,7 @@ static inline void sun3scsi_write(int re
sun3_scsi_regp[reg] = value;
}
+#ifndef SUN3_SCSI_VME
/* dma controller register access functions */
static inline unsigned short sun3_udc_read(unsigned char reg)
@@ -169,6 +177,7 @@ static inline void sun3_udc_write(unsign
dregs->udc_data = val;
udelay(SUN3_DMA_DELAY);
}
+#endif
/*
* XXX: status debug
@@ -187,17 +196,32 @@ static struct Scsi_Host *default_instanc
*
*/
-int __init sun3scsi_detect(struct scsi_host_template * tpnt)
+static int __init sun3scsi_detect(struct scsi_host_template * tpnt)
{
- unsigned long ioaddr;
+ unsigned long ioaddr, irq;
static int called = 0;
struct Scsi_Host *instance;
+#ifdef SUN3_SCSI_VME
+ int i;
+ unsigned long addrs[3] = { IOBASE_SUN3_VMESCSI,
+ IOBASE_SUN3_VMESCSI + 0x4000,
+ 0 };
+ unsigned long vecs[3] = { SUN3_VEC_VMESCSI0,
+ SUN3_VEC_VMESCSI1,
+ 0 };
+#endif
/* check that this machine has an onboard 5380 */
switch(idprom->id_machtype) {
+#ifdef SUN3_SCSI_VME
+ case SM_SUN3|SM_3_160:
+ case SM_SUN3|SM_3_260:
+ break;
+#else
case SM_SUN3|SM_3_50:
case SM_SUN3|SM_3_60:
break;
+#endif
default:
return 0;
@@ -206,7 +230,11 @@ int __init sun3scsi_detect(struct scsi_h
if(called)
return 0;
+#ifdef SUN3_SCSI_VME
+ tpnt->proc_name = "Sun3 5380 VME SCSI";
+#else
tpnt->proc_name = "Sun3 5380 SCSI";
+#endif
/* setup variables */
tpnt->can_queue =
@@ -223,6 +251,38 @@ int __init sun3scsi_detect(struct scsi_h
tpnt->this_id = 7;
}
+#ifdef SUN3_SCSI_VME
+ ioaddr = 0;
+ for(i = 0; addrs[i] != 0; i++) {
+ unsigned char x;
+
+ ioaddr = (unsigned long)sun3_ioremap(addrs[i], PAGE_SIZE,
+SUN3_PAGE_TYPE_VME16);
+ irq = vecs[i];
+ sun3_scsi_regp = (unsigned char *)ioaddr;
+
+ dregs = (struct sun3_dma_regs *)(((unsigned char *)ioaddr) + 8);
+
+ if(sun3_map_test((unsigned long)dregs, )) {
+ unsigned short oldcsr;
+
+ oldcsr = dregs->csr;
+ dregs->csr = 0;
+ udelay(SUN3_DMA_DELAY);
+ if(dregs->csr == 0x1400)
+ break;
+
+ dregs->csr = oldcsr;
+ }
+
+ iounmap((void *)ioaddr);
+ ioaddr = 0;
+ }
+
+ if(!ioaddr)
+ return 0;
+#else
+ irq = IRQ_SUN3_SCSI;
ioaddr = (unsigned long)ioremap(IOBASE_SUN3_SCSI, PAGE_SIZE);
sun3_scsi_regp = (unsigned char *)ioaddr;
@@ -233,11 +293,6 @@
[PATCH 11/12] scsi/NCR5380: reduce depth of sun3_scsi nested includes
Move the #include "NCR5380.h" out of the sun3_scsi.h header file and into
the driver .c files, like all the other NCR5380 drivers in the tree.
This improves uniformity and reduces the depth of nested includes. The
sequence of #include's, #define's and #if's no longer does my head in.
Signed-off-by: Finn Thain
---
Here's a graph showing the present #include structure.
sun3_scsi_vme.c -> sun3_scsi.h -> NCR5380.h
|^
'|.
||
.'|
| v
sun3_scsi.c -> sun3_NCR5380.c
And here's the situation at the end of this patch series, after moving the
#includes with this patch, and merging sun3_scsi.c and sun3_scsi_vme with
the next patch.
sun3_scsi.h
^
|
|
sun3_scsi_vme.c -> sun3_scsi.c -> sun3_NCR5380.c
|
|
v
NCR5380.h
The final structure (see the next patch) of sun3_scsi_vme mirrors that of
g_NCR5380_mmio.c, and the final structure of sun3_scsi mirrors that of all
the other NCR5380 drivers.
BTW, both sun3_scsi.c and sun3_scsi_vme.c also #include "initio.h"
but I've sent a separate patch to address this.
---
drivers/scsi/sun3_scsi.c |1 +
drivers/scsi/sun3_scsi.h |8 +++-
drivers/scsi/sun3_scsi_vme.c |1 +
3 files changed, 5 insertions(+), 5 deletions(-)
Index: linux-m68k/drivers/scsi/sun3_scsi.c
===
--- linux-m68k.orig/drivers/scsi/sun3_scsi.c2014-03-18 00:18:36.0
+1100
+++ linux-m68k/drivers/scsi/sun3_scsi.c 2014-03-18 00:18:38.0 +1100
@@ -72,6 +72,7 @@
#include "initio.h"
#include
#include "sun3_scsi.h"
+#include "NCR5380.h"
/* #define OLDDMA */
Index: linux-m68k/drivers/scsi/sun3_scsi.h
===
--- linux-m68k.orig/drivers/scsi/sun3_scsi.h2014-03-18 00:18:37.0
+1100
+++ linux-m68k/drivers/scsi/sun3_scsi.h 2014-03-18 00:18:38.0 +1100
@@ -29,8 +29,8 @@
* 1+ (800) 334-5454
*/
-#ifndef SUN3_NCR5380_H
-#define SUN3_NCR5380_H
+#ifndef SUN3_SCSI_H
+#define SUN3_SCSI_H
#define SUN3SCSI_PUBLIC_RELEASE 1
@@ -182,7 +182,5 @@ struct sun3_udc_regs {
#define VME_DATA24 0x3d00
-#include "NCR5380.h"
-
-#endif /* SUN3_NCR5380_H */
+#endif /* SUN3_SCSI_H */
Index: linux-m68k/drivers/scsi/sun3_scsi_vme.c
===
--- linux-m68k.orig/drivers/scsi/sun3_scsi_vme.c2014-03-18
00:18:36.0 +1100
+++ linux-m68k/drivers/scsi/sun3_scsi_vme.c 2014-03-18 00:18:38.0
+1100
@@ -42,6 +42,7 @@
#include "initio.h"
#include
#include "sun3_scsi.h"
+#include "NCR5380.h"
extern int sun3_map_test(unsigned long, char *);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/12] scsi/NCR5380: fix and standardize NDEBUG macros
All three NCR5380 core driver implementations share the same NCR5380.h
header file so they need to agree on certain macro definitions.
The flag bit used by the NDEBUG_MERGING macro in atari_NCR5380 and
sun3_NCR5380 collides with the bit used by NDEBUG_LISTS.
Moreover, NDEBUG_ABORT appears in NCR5380.c so it should be defined in
NCR5380.h rather than in each of the many drivers using that core.
An undefined NDEBUG_ABORT macro caused compiler errors and led to dodgy
workarounds in the core driver that can now be removed.
(See commits f566a576bca09de85bf477fc0ab2c8c96405b77b and
185a7a1cd79b9891e3c17abdb103ba1c98d6ca7a.)
Move all of the NDEBUG_ABORT, NDEBUG_TAGS and NDEBUG_MERGING macro
definitions into NCR5380.h where all the other NDEBUG macros live.
Also, incorrect "#ifdef NDEBUG" becomes "#if NDEBUG" to fix the warning:
drivers/scsi/mac_scsi.c: At top level:
drivers/scsi/NCR5380.c:418: warning: 'NCR5380_print' defined but not used
drivers/scsi/NCR5380.c:459: warning: 'NCR5380_print_phase' defined but not used
The debugging code is now enabled when NDEBUG != 0.
Signed-off-by: Finn Thain
---
drivers/scsi/NCR5380.c |7 ---
drivers/scsi/NCR5380.h | 22 ++
drivers/scsi/atari_NCR5380.c | 10 --
drivers/scsi/atari_scsi.c|6 --
drivers/scsi/dtc.c |2 --
drivers/scsi/mac_scsi.c |6 --
drivers/scsi/sun3_NCR5380.c |8 +---
drivers/scsi/sun3_scsi.c |6 --
drivers/scsi/sun3_scsi_vme.c |6 --
9 files changed, 19 insertions(+), 54 deletions(-)
Index: linux-m68k/drivers/scsi/NCR5380.h
===
--- linux-m68k.orig/drivers/scsi/NCR5380.h 2014-03-18 00:18:34.0
+1100
+++ linux-m68k/drivers/scsi/NCR5380.h 2014-03-18 00:18:36.0 +1100
@@ -56,6 +56,9 @@
#define NDEBUG_C400_PREAD 0x10
#define NDEBUG_C400_PWRITE 0x20
#define NDEBUG_LISTS 0x40
+#define NDEBUG_ABORT 0x80
+#define NDEBUG_TAGS0x100
+#define NDEBUG_MERGING 0x200
#define NDEBUG_ANY 0xUL
@@ -288,9 +291,24 @@ struct NCR5380_hostdata {
#ifdef __KERNEL__
+#ifndef NDEBUG
+#define NDEBUG (0)
+#endif
+
+#if NDEBUG
+#define dprintk(flg, fmt, args...) \
+ do { if ((NDEBUG) & (flg)) pr_debug(fmt, ## args); } while (0)
+#define NCR5380_dprint(flg, arg) \
+ do { if ((NDEBUG) & (flg)) NCR5380_print(arg); } while (0)
+#define NCR5380_dprint_phase(flg, arg) \
+ do { if ((NDEBUG) & (flg)) NCR5380_print_phase(arg); } while (0)
+static void NCR5380_print_phase(struct Scsi_Host *instance);
+static void NCR5380_print(struct Scsi_Host *instance);
+#else
#define dprintk(flg, fmt, args...) do {} while (0)
#define NCR5380_dprint(flg, arg) do {} while (0)
#define NCR5380_dprint_phase(flg, arg) do {} while (0)
+#endif
#if defined(AUTOPROBE_IRQ)
static int NCR5380_probe_irq(struct Scsi_Host *instance, int possible);
@@ -303,10 +321,6 @@ static irqreturn_t NCR5380_intr(int irq,
#endif
static void NCR5380_main(struct work_struct *work);
static void __maybe_unused NCR5380_print_options(struct Scsi_Host *instance);
-#ifdef NDEBUG
-static void NCR5380_print_phase(struct Scsi_Host *instance);
-static void NCR5380_print(struct Scsi_Host *instance);
-#endif
static int NCR5380_abort(Scsi_Cmnd * cmd);
static int NCR5380_bus_reset(Scsi_Cmnd * cmd);
static int NCR5380_queue_command(struct Scsi_Host *, struct scsi_cmnd *);
Index: linux-m68k/drivers/scsi/atari_scsi.c
===
--- linux-m68k.orig/drivers/scsi/atari_scsi.c 2014-03-18 00:18:36.0
+1100
+++ linux-m68k/drivers/scsi/atari_scsi.c2014-03-18 00:18:36.0
+1100
@@ -67,12 +67,6 @@
#include
-#define NDEBUG (0)
-
-#define NDEBUG_ABORT 0x0010
-#define NDEBUG_TAGS0x0020
-#define NDEBUG_MERGING 0x0040
-
#define AUTOSENSE
/* For the Atari version, use only polled IO or REAL_DMA */
#defineREAL_DMA
Index: linux-m68k/drivers/scsi/NCR5380.c
===
--- linux-m68k.orig/drivers/scsi/NCR5380.c 2014-03-18 00:18:34.0
+1100
+++ linux-m68k/drivers/scsi/NCR5380.c 2014-03-18 00:18:36.0 +1100
@@ -87,13 +87,6 @@
#include
#include
-#ifndef NDEBUG
-#define NDEBUG 0
-#endif
-#ifndef NDEBUG_ABORT
-#define NDEBUG_ABORT 0
-#endif
-
#if (NDEBUG & NDEBUG_LISTS)
#define LIST(x,y) {printk("LINE:%d Adding %p to %p\n", __LINE__, (void*)(x),
(void*)(y)); if ((x)==(y)) udelay(5); }
#define REMOVE(w,x,y,z) {printk("LINE:%d Removing: %p->%p %p->%p \n",
__LINE__, (void*)(w), (void*)(x), (void*)(y), (void*)(z)); if ((x)==(y))
udelay(5); }
Index: linux-m68k/drivers/scsi/sun3_scsi_vme.c
===
---
[PATCH 01/12] scsi/NCR5380: remove unused BOARD_NORMAL and BOARD_NCR53C400
BOARD_NORMAL is completely unused and BOARD_NCR53C400 is used only by
g_NCR5380 internally. Remove the unused definitions.
Signed-off-by: Finn Thain
---
drivers/scsi/arm/cumana_1.c |3 ---
drivers/scsi/arm/oak.c |3 ---
drivers/scsi/mac_scsi.h |3 ---
drivers/scsi/sun3_scsi.h|3 ---
4 files changed, 12 deletions(-)
Index: linux-m68k/drivers/scsi/arm/cumana_1.c
===
--- linux-m68k.orig/drivers/scsi/arm/cumana_1.c 2014-03-17 23:49:31.0
+1100
+++ linux-m68k/drivers/scsi/arm/cumana_1.c 2014-03-18 00:18:20.0
+1100
@@ -36,9 +36,6 @@
void __iomem *base; \
void __iomem *dma
-#define BOARD_NORMAL 0
-#define BOARD_NCR53C4001
-
#include "../NCR5380.h"
void cumanascsi_setup(char *str, int *ints)
Index: linux-m68k/drivers/scsi/arm/oak.c
===
--- linux-m68k.orig/drivers/scsi/arm/oak.c 2014-03-17 23:49:31.0
+1100
+++ linux-m68k/drivers/scsi/arm/oak.c 2014-03-18 00:18:20.0 +1100
@@ -37,9 +37,6 @@
#define NCR5380_implementation_fields \
void __iomem *base
-#define BOARD_NORMAL 0
-#define BOARD_NCR53C4001
-
#include "../NCR5380.h"
#undef START_DMA_INITIATOR_RECEIVE_REG
Index: linux-m68k/drivers/scsi/mac_scsi.h
===
--- linux-m68k.orig/drivers/scsi/mac_scsi.h 2014-03-17 23:49:31.0
+1100
+++ linux-m68k/drivers/scsi/mac_scsi.h 2014-03-18 00:18:20.0 +1100
@@ -75,9 +75,6 @@
#define NCR5380_show_info macscsi_show_info
#define NCR5380_write_info macscsi_write_info
-#define BOARD_NORMAL 0
-#define BOARD_NCR53C4001
-
#endif /* ndef HOSTS_C */
#endif /* ndef ASM */
#endif /* MAC_NCR5380_H */
Index: linux-m68k/drivers/scsi/sun3_scsi.h
===
--- linux-m68k.orig/drivers/scsi/sun3_scsi.h2014-03-17 23:49:31.0
+1100
+++ linux-m68k/drivers/scsi/sun3_scsi.h 2014-03-18 00:18:20.0 +1100
@@ -108,9 +108,6 @@ static int sun3scsi_release (struct Scsi
#define NCR5380_dma_read_setup(instance, data, count) sun3scsi_dma_setup(data,
count, 0)
#define NCR5380_dma_residual sun3scsi_dma_residual
-#define BOARD_NORMAL 0
-#define BOARD_NCR53C4001
-
/* additional registers - mainly DMA control regs */
/* these start at regbase + 8 -- directly after the NCR regs */
struct sun3_dma_regs {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/12] scsi/NCR5380: fix debugging macros and #include structure
(Second attempt... sorry for the earlier spam.) This patch series addresses several issues with NCR5380 drivers: 1. The complex network of #include directives. 2. Three inconsistent implementations of the core driver all attempting to share the same macro definitions in NCR5380.h. 3. Broken debugging code. In the past these issues have led to compiler warnings and ugly hacks to fix build failures. This patch series fixes the debugging code by reducing the divergence between the various core driver implementations. The final two patches in the series further reduce divergence by refactoring sun3_scsi.c and sun3_scsi_vme.c so that they follow the same structure as the other NCR5380 drivers. By the end of this patch series over 800 net lines of code have been removed. This is mostly duplicated code that's easily eliminated once the debugging code is made consistent (and some dead code is removed). Better uniformity and less duplication should assist future work such as modernization and trivial clean-up. To make code review easier I've tried to keep these patches succinct and free of extraneous changes. Though I did run checkpatch.pl, I've ignored whitespace issues in existing code. I will send separate patches for whitespace clean-up of NCR5380 drivers. All NCR5380 drivers have been compile-tested with this patch series: arm/cumana_1.c arm/oak.c atari_scsi.c dmx3191d.c dtc.c g_NCR5380.c g_NCR5380_mmio.c mac_scsi.c pas16.c sun3_scsi.c sun3_scsi_vme.c t128.c I've successfully regression tested this patch series using mac_scsi on a PowerBook 180. The debugging macros are now usable again. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/12] scsi/NCR5380: fix build failures when debugging is enabled
The change from cmd->target to cmd->device->id was apparently the purpose of
commit a7f251228390e87d86c5e3846f99a455517fdd8e in
kernel/git/tglx/history.git but some instances have been missed.
Also fix the "NDEBUG_LAST_WRITE_SENT" and "NDEBUG_ALL" typo's.
Also fix some format strings (%ul becomes %lu) that caused compiler warnings.
Signed-off-by: Finn Thain
---
drivers/scsi/NCR5380.c | 14 +++---
drivers/scsi/sun3_NCR5380.c |4 ++--
2 files changed, 9 insertions(+), 9 deletions(-)
Index: linux-m68k/drivers/scsi/sun3_NCR5380.c
===
--- linux-m68k.orig/drivers/scsi/sun3_NCR5380.c 2014-03-17 23:49:27.0
+1100
+++ linux-m68k/drivers/scsi/sun3_NCR5380.c 2014-03-18 00:18:34.0
+1100
@@ -1049,7 +1049,7 @@ static void NCR5380_main (struct work_st
*/
MAIN_PRINTK("scsi%d: main(): command for target %d "
"lun %d removed from issue_queue\n",
- HOSTNO, tmp->target, tmp->lun);
+ HOSTNO, tmp->device->id, tmp->device->lun);
/*
* REQUEST SENSE commands are issued without tagged
* queueing, even on SCSI-II devices because the
@@ -2587,7 +2587,7 @@ static void NCR5380_reselect (struct Scs
hostdata->connected = tmp;
RSL_PRINTK("scsi%d: nexus established, target = %d, lun = %d, tag = %d\n",
- HOSTNO, tmp->target, tmp->lun, tmp->tag);
+ HOSTNO, tmp->device->id, tmp->device->lun, tmp->tag);
}
Index: linux-m68k/drivers/scsi/NCR5380.c
===
--- linux-m68k.orig/drivers/scsi/NCR5380.c 2014-03-18 00:18:32.0
+1100
+++ linux-m68k/drivers/scsi/NCR5380.c 2014-03-18 00:18:34.0 +1100
@@ -1046,7 +1046,7 @@ static void NCR5380_main(struct work_str
for (tmp = (Scsi_Cmnd *) hostdata->issue_queue, prev =
NULL; tmp; prev = tmp, tmp = (Scsi_Cmnd *) tmp->host_scribble)
{
if (prev != tmp)
- dprintk(NDEBUG_LISTS, ("MAIN tmp=%p
target=%d busy=%d lun=%d\n", tmp, tmp->target, hostdata->busy[tmp->target],
tmp->lun));
+ dprintk(NDEBUG_LISTS, ("MAIN tmp=%p
target=%d busy=%d lun=%d\n", tmp, tmp->device->id,
hostdata->busy[tmp->device->id], tmp->device->lun));
/* When we find one, remove it from the issue
queue. */
if (!(hostdata->busy[tmp->device->id] & (1 <<
tmp->device->lun))) {
if (prev) {
@@ -1064,7 +1064,7 @@ static void NCR5380_main(struct work_str
* On failure, we must add the command
back to the
* issue queue so we can keep trying.
*/
- dprintk(NDEBUG_MAIN|NDEBUG_QUEUES,
("scsi%d : main() : command for target %d lun %d removed from issue_queue\n",
instance->host_no, tmp->target, tmp->lun));
+ dprintk(NDEBUG_MAIN|NDEBUG_QUEUES,
("scsi%d : main() : command for target %d lun %d removed from issue_queue\n",
instance->host_no, tmp->device->id, tmp->device->lun));
/*
* A successful selection is defined as
one that
@@ -2028,7 +2028,7 @@ static int NCR5380_transfer_dma(struct S
hostdata->flags &=
~FLAG_CHECK_LAST_BYTE_SENT;
if (NCR5380_read(TARGET_COMMAND_REG) &
TCR_LAST_BYTE_SENT) {
hostdata->flags |=
FLAG_HAS_LAST_BYTE_SENT;
- dprintk(NDEBUG_LAST_WRITE_SENT,
("scsi%d : last bit sent works\n", instance->host_no));
+ dprintk(NDEBUG_LAST_BYTE_SENT,
("scsi%d : last byte sent works\n", instance->host_no));
}
}
} else {
@@ -2454,7 +2454,7 @@ static void NCR5380_information_transfer
NCR5380_transfer_pio(instance, , ,
);
if (!cmd->device->disconnect &&
should_disconnect(cmd->cmnd[0])) {
NCR5380_set_timer(hostdata,
USLEEP_SLEEP);
- dprintk(NDEBUG_USLEEP, ("scsi%d :
issued command, sleeping until %ul\n", instance->host_no,
hostdata->time_expires));
+ dprintk(NDEBUG_USLEEP, ("scsi%d :
issued command, sleeping until %lu\n", instance->host_no,
hostdata->time_expires));
Re: [RFC PATCH 0/4] power_supply: Add DT helper function to get power-supply dev from dt
Hi, On Mon, Mar 17, 2014 at 09:43:43PM +0900, Chanwoo Choi wrote: > This patchset add DT helper function to get power-supply device from > devicetree. > - of_power_supply_get_dev(struct device *dev, enum power_supply_dev_type type, > int index) > Power-supply class provides 'power_supply_get_by_name()' to users who want to > find power-supply device with the name of power-supply device. > > If CONFIG_OF is enabled, device drivers which want to get power-supply device > would directly get the power-supply device from devicetree by using of_power_ > supply_get_dev(). This function can be used instead of > power_supply_get_by_name(). > > For example, > [...] include/linux/power_supply.h provides the following function already: struct power_supply * power_supply_get_by_phandle(struct device_node *np, const char *property); -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 1/3] vrange: Add vrange syscall and handle splitting/merging and marking vmas
On 03/17/2014 02:43 AM, Jan Kara wrote:
> On Mon 17-03-14 10:21:18, Jan Kara wrote:
>> On Fri 14-03-14 11:33:31, John Stultz wrote:
>>> + for (;;) {
>>> + unsigned long new_flags;
>>> + pgoff_t pgoff;
>>> + unsigned long tmp;
>>> +
>>> + if (!vma)
>>> + goto out;
>>> +
>>> + if (vma->vm_flags & (VM_SPECIAL|VM_LOCKED|VM_MIXEDMAP|
>>> + VM_HUGETLB))
>>> + goto out;
>>> +
>>> + /* We don't support volatility on files for now */
>>> + if (vma->vm_file) {
>>> + ret = -EINVAL;
>>> + goto out;
>>> + }
>>> +
>>> + new_flags = vma->vm_flags;
>>> +
>>> + if (start < vma->vm_start) {
>>> + start = vma->vm_start;
>>> + if (start >= end)
>>> + goto out;
>>> + }
> One more question: This seems to silently skip any holes between VMAs. Is
> that really intended? I'd expect that marking unmapped range as volatile /
> non-volatile should return error... In any case what happens should be
> defined in the description.
So.. initially it was by design, but as I look at madvise and think
about it further, it does make more sense to throw errors if memory in
the range is not mapped.
I'll try to rework things to adapt to this.
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: unisys: use kzalloc instead of kmalloc/memset 0
On Tue, Mar 18, 2014 at 09:26:07AM +0900, DaeSeok Youn wrote: > I think vmalloc/kmalloc in uislib_malloc() can be removed and just use > vmalloc/kmalloc directly. Yes. Actually, just use kmalloc, I don't knwo why vmalloc is being used, but cc: the driver maintainers just to be sure. > (UISMALLOC() macro is also removed.) Yes. > And uislib_malloc() is renamed to "uislib_trace_buffer_status()" which > is just tracing buffer status(Malloc_FailuresAlloc, Malloc_BytesInUse > ...) for info_proc_read_helper(). The whole tracing stuff needs to be ripped out, so no problem deleting it here as well. > If this change is accepted, it also need to change uislib_free(). Drop it and just use kfree(). thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [f2fs-dev] [PATCH] f2fs: fix incorrect parsing with option string
Hi,
2014-03-17 (월), 17:40 +0800, Chao Yu:
> Previously 'background_gc={on***,off***}' is being parsed as correct option,
> with this patch we cloud fix the trivial bug in mount process.
>
> Signed-off-by: Chao Yu
> ---
> fs/f2fs/super.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index 057a3ef..6597290 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -258,9 +258,9 @@ static int parse_options(struct super_block *sb, char
> *options)
>
> if (!name)
> return -ENOMEM;
> - if (!strncmp(name, "on", 2))
> + if (!strncmp(name, "on", strlen(name)))
What about 'background_gc=o'?
Need to check strlen(name) == 2...
Thanks,
> set_opt(sbi, BG_GC);
> - else if (!strncmp(name, "off", 3))
> + else if (!strncmp(name, "off", strlen(name)))
> clear_opt(sbi, BG_GC);
> else {
> kfree(name);
--
Jaegeuk Kim
Samsung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH 2/2] ACPI: Default disable auto-serialization.
Hi, Rafael
> From: Wysocki, Rafael J
> Sent: Monday, March 17, 2014 8:09 PM
>
> On 3/17/2014 5:14 AM, Lv Zheng wrote:
> > This feature enabled by the following commit is still under development.
> >
> >Commit: cd52379678785b02d7a357988cfba214fdaf92f4
> >Subject: ACPICA: Add global option to disable method auto-serialization.
> >This change adds an option to disable the auto-serialization of
> >methods that create named objects.
> >
> > This patch disables it by default temporarily according to the bug reports.
>
> Well, it doesn't restore the 3.14 behavior of acpi_auto_serialize, as
> far as I can say, so we can't apply it.
>
> I still can drop the commits related to auto-serialization from my
> acpica branch. Which commits are they?
>From linux-pm/bleeding-edge branch, I found this series includes the following
>commits:
Commit: a0fd108f2da56b769472fc0095616fb370988516
Author: Lv Zheng
Subject: ACPI: Rename kernel parameter "acpi_serialize" to
"acpi_no_auto_serialize"
Commit: 5f1cb4a92e4c4aabd139ff9ca1e11c0e2db2ac59
Author: Lv Zheng
Subject: ACPICA: Remove global option to serialize all control methods.
Commit: cd52379678785b02d7a357988cfba214fdaf92f4
Author: Bob Moore
Subject: ACPICA: Add global option to disable method auto-serialization.
Commit: f56b05bd111b01141ef74568dc4d262c70295d03
Author: Lv Zheng
Subject: ACPICA: Add additional named objects for the auto-serialize method
scan.
Commit: 27f1899350a1d6baab117c03c87f0e37730047bd
Author: Bob Moore
Subject: ACPICA: Add auto-serialization support for ill-behaved control methods.
Reverting these commits can restore original Linux behavior.
Please check.
Thanks and best regards
-Lv
>
> > References: http://www.spinics.net/lists/linux-acpi/msg49496.html
> > Reported-by: Valdis Kletnieks
> > Reported-by: Sabrina Dubroka
> > Signed-off-by: Lv Zheng
> > ---
> > Documentation/kernel-parameters.txt |8
> > drivers/acpi/acpica/acglobal.h |2 +-
> > drivers/acpi/osl.c | 12 ++--
> > 3 files changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/Documentation/kernel-parameters.txt
> > b/Documentation/kernel-parameters.txt
> > index 91f0be8..a159537 100644
> > --- a/Documentation/kernel-parameters.txt
> > +++ b/Documentation/kernel-parameters.txt
> > @@ -229,13 +229,13 @@ bytes respectively. Such letter suffixes can also be
> > entirely omitted.
> > use by PCI
> > Format: ,...
> >
> > - acpi_no_auto_serialize [HW,ACPI]
> > - Disable auto-serialization of AML methods
> > + acpi_auto_serialize [HW,ACPI]
> > + Enable auto-serialization of AML methods
> > AML control methods that contain the opcodes to create
> > named objects will be marked as "Serialized" by the
> > auto-serialization feature.
> > - This feature is enabled by default.
> > - This option allows to turn off the feature.
> > + This feature is disabled by default.
> > + This option allows to turn on the feature.
> >
> > acpi_no_auto_ssdt [HW,ACPI] Disable automatic loading of SSDT
> >
> > diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
> > index 49bbc71..ea0f838 100644
> > --- a/drivers/acpi/acpica/acglobal.h
> > +++ b/drivers/acpi/acpica/acglobal.h
> > @@ -99,7 +99,7 @@ ACPI_INIT_GLOBAL(u8, acpi_gbl_enable_interpreter_slack,
> > FALSE);
> >* that create named objects are marked Serialized in order to prevent
> >* possible run-time problems if they are entered by more than one thread.
> >*/
> > -ACPI_INIT_GLOBAL(u8, acpi_gbl_auto_serialize_methods, TRUE);
> > +ACPI_INIT_GLOBAL(u8, acpi_gbl_auto_serialize_methods, FALSE);
> >
> > /*
> >* Create the predefined _OSI method in the namespace? Default is TRUE
> > diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> > index d40d6dc..928f0c2 100644
> > --- a/drivers/acpi/osl.c
> > +++ b/drivers/acpi/osl.c
> > @@ -1538,20 +1538,20 @@ static int __init osi_setup(char *str)
> > __setup("acpi_osi=", osi_setup);
> >
> > /*
> > - * Disable the auto-serialization of named objects creation methods.
> > + * Enable the auto-serialization of named objects creation methods.
> >*
> > - * This feature is enabled by default. It marks the AML control methods
> > + * This feature is disabled by default. It marks the AML control methods
> >* that contain the opcodes to create named objects as "Serialized".
> >*/
> > -static int __init acpi_no_auto_serialize_setup(char *str)
> > +static int __init acpi_auto_serialize_setup(char *str)
> > {
> > - acpi_gbl_auto_serialize_methods = FALSE;
> > - pr_info("ACPI: auto-serialization disabled\n");
> > + acpi_gbl_auto_serialize_methods = TRUE;
> > + pr_info("ACPI: auto-serialization enabled\n");
> >
> > return 1;
> > }
> >
> >
Re: [PATCH 8/9] PCI: Ignore BAR contents when firmware left decoding disabled
On Fri, Mar 14, 2014 at 09:48:35AM +0800, Ming Lei wrote: > On Fri, Mar 14, 2014 at 12:08 AM, Bjorn Helgaas wrote: > > On Thu, Mar 13, 2014 at 2:51 AM, Ming Lei wrote: > >> Hi Bjorn, > >> > >> I found this patch broke virtio-pci devices. > > > > Thanks a lot for testing this. > > > >> On Thu, Feb 27, 2014 at 3:37 AM, Bjorn Helgaas wrote: > >>> Don't rely on BAR contents when the command register says the BAR is > >>> disabled. > >>> > >>> If we receive a PCI device from firmware (or a hot-added device that was > >>> just powered up) with the MEMORY or IO enable bits in the PCI command > >>> register cleared, there's no reason to believe the BARs contain valid > >>> addresses. > >> > >> From PCI LOCAL BUS SPECIFICATION, REV. 3.0, both > >> PCI_COMMAND_IO and PCI_COMMAND_MEM should be > >> cleared after reset, so looks the patch sets IORESOURCE_UNSET > >> too early because PCI drivers may call pci_enable_device() > >> (->pci_enable_resources()) to enable the two bits of > >> PCI_COMMAND explicitly. > > > > The point is that it's not safe to enable those two bits unless we're > > certain that the BARs they control contain valid values that don't > > conflict with anything else in the system. > > > > Maybe we should only set IORESOURCE_UNSET when we find a conflict or a > > BAR that's not contained by an upstream bridge window, and we should > > try to reallocate then. I'm pretty sure we do that at least in some > > cases, but it would probably simplify things if we did it more > > consistently, and maybe we shouldn't set it at all here in > > __pci_read_base(). > > I think so because __pci_read_base() is called in device emulation > path. Which path is this? I don't know anything about virtio-pci, and I only see calls to __pci_read_base() from: sriov_init() pci_sriov_resource_alignment() pci_read_bases() > > But I'd like to understand your situation better, so can you provide > > more details, please? Complete before/after dmesg logs would go a > > long way toward illustrating the problem you're seeing. > > Please see the two attachment log. The memory allocation failure > is caused by mistaken value read from pci address after the device > is failed to enable. Your logs are harder than necessary to compare because one has a lot more debug turned on than the other. In the failing case, we ignore all the initial BAR values, but we do assign values to all of them later: pci :00:00.0: can't claim BAR 0 [mem size 0x0400]: no address assigned pci :00:00.0: can't claim BAR 1 [io size 0x0400]: no address assigned ... pci :00:00.0: BAR 0: assigned [mem 0x4000-0x43ff] pci :00:00.0: BAR 1: assigned [io 0x1000-0x13ff] ... The newly-assigned values look valid, and as far as I can tell, they should work. Do you know why they don't? Is there an assumption somewhere that we never change BAR values? Even if we don't need to ignore BAR values in as many cases as we do, it should be legal to ignore them and reassign them, so I want to understand what's going on here before reverting this. Is there an easy way I can reproduce the problem on my own box? Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: unisys: use kzalloc instead of kmalloc/memset 0
I think vmalloc/kmalloc in uislib_malloc() can be removed and just use
vmalloc/kmalloc directly.
(UISMALLOC() macro is also removed.)
And uislib_malloc() is renamed to "uislib_trace_buffer_status()" which
is just tracing buffer status(Malloc_FailuresAlloc, Malloc_BytesInUse
...) for info_proc_read_helper().
If this change is accepted, it also need to change uislib_free().
Is it fine to change like this?
Thanks.
Daeseok Youn.
2014-03-18 6:41 GMT+09:00 Greg KH :
> On Wed, Mar 12, 2014 at 07:37:50PM +0900, Daeseok Youn wrote:
>>
>> Signed-off-by: Daeseok Youn
>> ---
>> drivers/staging/unisys/uislib/uislib.c |5 +
>> drivers/staging/unisys/uislib/uisutils.c |2 +-
>> 2 files changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/staging/unisys/uislib/uislib.c
>> b/drivers/staging/unisys/uislib/uislib.c
>> index d77df9a..9748fcb 100644
>> --- a/drivers/staging/unisys/uislib/uislib.c
>> +++ b/drivers/staging/unisys/uislib/uislib.c
>> @@ -339,8 +339,6 @@ create_bus(CONTROLVM_MESSAGE *msg, char *buf)
>> return CONTROLVM_RESP_ERROR_KMALLOC_FAILED;
>> }
>>
>> - memset(bus, 0, size);
>> -
>> /* Currently by default, the bus Number is the GuestHandle.
>>* Configure Bus message can override this.
>>*/
>> @@ -530,7 +528,6 @@ create_device(CONTROLVM_MESSAGE *msg, char *buf)
>> return CONTROLVM_RESP_ERROR_KMALLOC_FAILED;
>> }
>>
>> - memset(dev, 0, sizeof(struct device_info));
>> dev->channelTypeGuid = msg->cmd.createDevice.dataTypeGuid;
>> dev->intr = msg->cmd.createDevice.intr;
>> dev->channelAddr = msg->cmd.createDevice.channelAddr;
>> @@ -1437,7 +1434,7 @@ uislib_malloc(size_t siz, gfp_t gfp, U8 contiguous,
>> char *fn, int ln)
>> * get memory for you (like, invoke oom killer), which
>> * will probably cripple the system.
>> */
>> - p = kmalloc(siz, gfp | __GFP_NORETRY);
>> + p = kzalloc(siz, gfp | __GFP_NORETRY);
>> }
>> if (p == NULL) {
>> LOGERR("uislib_malloc failed to alloc %d bytes @%s:%d",
>> diff --git a/drivers/staging/unisys/uislib/uisutils.c
>> b/drivers/staging/unisys/uislib/uisutils.c
>> index 208b7ea..2f05be1 100644
>> --- a/drivers/staging/unisys/uislib/uisutils.c
>> +++ b/drivers/staging/unisys/uislib/uisutils.c
>> @@ -294,7 +294,7 @@ ReqHandlerAdd(GUID switchTypeGuid,
>> rc = UISMALLOC(sizeof(*rc), GFP_ATOMIC);
>> if (!rc)
>> return NULL;
>> - memset(rc, 0, sizeof(*rc));
>> +
>> rc->switchTypeGuid = switchTypeGuid;
>> rc->controlfunc = controlfunc;
>> rc->min_channel_bytes = min_channel_bytes;
>
> Can you just remove the UISMALLOC() macro completly, so that it's easier
> to verify that changes like this are actually correct?
>
> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the driver-core tree
On Mon, 2014-03-17 at 18:21 -0400, Tejun Heo wrote: > So, looked at the failed code. The only necessary change seems to be > calling device_remove_file_self() in dump_ack_store() and then doing > kobject_put() directly afterwards, which would have been completely > fine as a merge fix patch. Ok. Since there's no merge error, I'll have to tell Linus explicitly to apply it during the merge. I've never done that before but I suppose it's doable. > Just to be clear, I'm not necessarily against reverting the removal of > the API. The removal was based on the speculation that this isn't > likely to cause trouble. The speculation was perfectly reasonable but > being a speculation it failed, so we take actions to remedy that and > we *do* want to do things that way. Reverting the removal can sure be > one choice but the way that choice is being made here seems completely > wrong to me. There's no technical evaluation whatsoever. I'd really > hate to work in an environment where taking active trade off is > discouraged replaced with blind policy enforcement. Sorry I don't understand. Reverting the removal until after -rc1 (or later in the merge window) is the easiest path from my perspective and ensure no bisection breakage but whatever Linus prefers works here. I don't think it's a drastic action or anything like that. It can trivially be re-applied once the merge window has settled. But I'm happy to also just send Linus a "apply this as a merge fixup" patch if he's happy with the method (as I said, I've never done that before on something that doesn't have an actual merge conflict to begin with) Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the mvebu tree with the arm-soc tree
Hi all,
Today's linux-next merge of the mvebu tree got a conflict in
arch/arm/boot/dts/Makefile between commit 8fc1b0f87d9f ("ARM: qcom: Split
Qualcomm support into legacy and multiplatform") from the arm-soc tree
and commits 97623e934388 ("Merge branch 'mvebu/dt' into for-next") and
54cab10f63f2 ("Merge branch 'mvebu/soc3' into next/dt") from the mvebu
tree.
I fixed it up (which produced no git diff) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpM5wNN6BLU0.pgp
Description: PGP signature
Re: [tip:x86/urgent] x86 idle: Repair large-server 50-watt idle-power regression
On Thu, 2013-12-19 at 11:51 -0800, tip-bot for Len Brown wrote: > Commit-ID: 40e2d7f9b5dae048789c64672bf3027fbb663ffa > Gitweb: http://git.kernel.org/tip/40e2d7f9b5dae048789c64672bf3027fbb663ffa > Author: Len Brown > AuthorDate: Wed, 18 Dec 2013 16:44:57 -0500 > Committer: H. Peter Anvin > CommitDate: Thu, 19 Dec 2013 11:47:39 -0800 > > x86 idle: Repair large-server 50-watt idle-power regression FYI this commit can cause some non trivial performance regressions for larger core count systems. While not surprising because of the nature of the change, having intel_idle do more cacheline invalidations, I still wanted to let you guys know. For instance, on a 160 core Westmere system, aim7 throughput can go down in a number of tests, anywhere from -10% to -25%. I guess it comes down to one of those performance vs energy things. And sure, max_cstate can be set to overcome this, but it's still something that was previously taken for granted. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [staging][r8188eu]: memory leak in rtw_free_cmd_obj if command is (_Set_Drv_Extra)
pcmd->parmbuf->pbuf has been allocated if command is
GEN_CMD_CODE(_Set_Drv_Extra),
and it enqueued by rtw_enqueue_cmd. rtw_cmd_thread dequeue pcmd by
rtw_dequeue_cmd.
The memory leak happened on this branch "if( _FAIL == rtw_cmd_filter(pcmdpriv,
pcmd) )"
which goto post_process directly against freeing pcmd->parmbuf->pbuf in
rtw_drvextra_cmd_hdl which is the cmd_hdl if command is (_Set_Drv_Extra).
This patch free pcmd->parmbuf->pbuf on the forgotten branch to avoid memory
leak.
Signed-off-by: Zhang Dongxing
Signed-off-by: xiaoming wang
diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c
b/drivers/staging/rtl8188eu/core/rtw_cmd.c
index c0a0a52..1c7f505 100644
--- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
+++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
@@ -288,7 +288,7 @@ int rtw_cmd_thread(void *context)
void (*pcmd_callback)(struct adapter *dev, struct cmd_obj *pcmd);
struct adapter *padapter = (struct adapter *)context;
struct cmd_priv *pcmdpriv = &(padapter->cmdpriv);
-
+ struct drvextra_cmd_parm *extra_parm = NULL;
thread_enter("RTW_CMD_THREAD");
@@ -323,6 +323,11 @@ _next:
if (_FAIL == rtw_cmd_filter(pcmdpriv, pcmd)) {
pcmd->res = H2C_DROPPED;
+ if (pcmd->cmdcode == GEN_CMD_CODE(_Set_Drv_Extra)) {
+ extra_parm = (struct drvextra_cmd_parm
*)pcmd->parmbuf;
+ if (extra_parm && extra_parm->pbuf &&
extra_parm->size > 0)
+ rtw_mfree(extra_parm->pbuf,
extra_parm->size);
+ }
goto post_process;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the driver-core tree
On Mon, 2014-03-17 at 14:56 -0700, Greg KH wrote: > No you can't, sorry. > > And this seems like a huge abuse of sysfs, you better be using binary > sysfs files for your log data... > > Do you have a pointer to where you document this sysfs api in > Documentation/ABI/ ? Yes, the patch adds the documentation along with the facility, I've attached the doc file to this email. This is a wrapper on top of firmware interfaces, in a way we are following ACPI precedent of exposing a bunch of things via sysfs, which also happen to be a simple and very convenient way of doing it. The log itself is a binary attribute in PEL format (or SEL when we support that), we have a userspace parser. > > Now regarding the practicals of sorting out our trees, Stephen suggested > > that rather than doing anything on my side (heh, I like that !), you > > should revert the last patch of the series, the one removing the old > > API, in your tree. > > > > It can then be re-applied later around rc1. > > I'll look to see if we can do that, let me dig it up out of my tree... Thanks. That's how Stephen is fixing it up in -next at the moment. Cheers, Ben. > thanks, > > greg k-h > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ What: /sys/firmware/opal/elog Date: Feb 2014 Contact:Stewart Smith Description: This directory exposes error log entries retrieved through the OPAL firmware interface. Each error log is identified by a unique ID and will exist until explicitly acknowledged to firmware. Each log entry has a directory in /sys/firmware/opal/elog. Log entries may be purged by the service processor before retrieved by firmware or retrieved/acknowledged by Linux if there is no room for more log entries. In the event that Linux has retrieved the log entries but not explicitly acknowledged them to firmware and the service processor needs more room for log entries, the only remaining copy of a log message may be in Linux. Typically, a user space daemon will monitor for new entries, read them out and acknowledge them. The service processor may be able to store more log entries than firmware can, so after you acknowledge an event from Linux you may instantly get another one from the queue that was generated some time in the past. The raw log format is a binary format. We currently do not parse this at all in kernel, leaving it up to user space to solve the problem. In future, we may do more parsing in kernel and add more files to make it easier for simple user space processes to extract more information. For each log entry (directory), there are the following files: id: An ASCII representation of the ID of the error log, in hex - e.g. "0x01". type: An ASCII representation of the type id and description of the type of error log. Currently just "0x00 PEL" - platform error log. In the future there may be additional types. raw:A read-only binary file that can be read to get the raw log entry. These are <16kb, often just hundreds of bytes and "average" 2kb. acknowledge:Writing 'ack' to this file will acknowledge the error log to firmware (and in turn the service processor, if applicable). Shortly after acknowledging it, the log entry will be removed from sysfs. Reading this file will list the supported operations (curently just acknowledge).
Re: linux-next: build failure after merge of the driver-core tree
Tejun Heo writes: > On Mon, Mar 17, 2014 at 06:05:54PM -0400, Tejun Heo wrote: >> I think this is being blown out of proportion. It was a rarely used >> API and converting to the new one is mostly trivial which can be > > So, looked at the failed code. The only necessary change seems to be > calling device_remove_file_self() in dump_ack_store() and then doing > kobject_put() directly afterwards, which would have been completely > fine as a merge fix patch. I had a quick look too and this seems correct (at least if my reading on howto use sysfs APIs is correct). I'm happy to post a patch somewhere - I guess it's easiest if the removal waits for one linus merge things cycle and then I can get fix and removal in? I'm not too fussed. > Just to be clear, I'm not necessarily against reverting the removal of > the API. The removal was based on the speculation that this isn't > likely to cause trouble. The speculation was perfectly reasonable but > being a speculation it failed, so we take actions to remedy that and > we *do* want to do things that way. Reverting the removal can sure be > one choice but the way that choice is being made here seems completely > wrong to me. There's no technical evaluation whatsoever. I'd really > hate to work in an environment where taking active trade off is > discouraged replaced with blind policy enforcement. I use an API and it changes/disappears - it's a gift I have :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sched: Initialize rq->age_stamp on processor start
From: Corey Minyard
If the sched_clock time starts at a large value, the kernel will spin
in sched_avg_update for a long time while rq->age_stamp catches up
with rq->clock.
The comment in kernel/sched/clock.c says that there is no strict promise
that it starts at zero. So initialize rq->age_stamp when a cpu starts up
to avoid this.
I was seeing long delays on a simulator that didn't start the clock at
zero. This might also be an issue on reboots on processors that don't
re-initialize the timer to zero on reset, and when using kexec.
Signed-off-by: Corey Minyard
---
kernel/sched/core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index b46131e..5be3d4a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5037,11 +5037,20 @@ static struct notifier_block migration_notifier = {
.priority = CPU_PRI_MIGRATION,
};
+static void __cpuinit set_cpu_rq_start_time(void)
+{
+ int cpu = smp_processor_id();
+ struct rq *rq = cpu_rq(cpu);
+ rq->age_stamp = sched_clock_cpu(cpu);
+}
+
static int sched_cpu_active(struct notifier_block *nfb,
unsigned long action, void *hcpu)
{
switch (action & ~CPU_TASKS_FROZEN) {
case CPU_STARTING:
+ set_cpu_rq_start_time();
+ /* fall through */
case CPU_DOWN_FAILED:
set_cpu_active((long)hcpu, true);
return NOTIFY_OK;
@@ -6922,6 +6931,7 @@ void __init sched_init(void)
init_sched_fair_class();
scheduler_running = 1;
+ set_cpu_rq_start_time();
}
#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
USB, TTY, char/misc, and Staging trees now closed for 3.15
Hi all, Given that 3.14 will be out in a few days, it's time to close my trees for new patches until 3.15-rc1 is out. Please feel free to send me patches for these trees, but note that I'll be ignoring them until 3.15-rc1 is out, at which point in time I'll start reviewing them again and applying them to the various places they belong. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the driver-core tree
Greg KH writes: > On Tue, Mar 18, 2014 at 07:33:30AM +1100, Benjamin Herrenschmidt wrote: >> On Mon, 2014-03-17 at 11:33 -0700, Greg KH wrote: >> >> > There were only 3 (or 4), users of this api, and no new ones had been >> > added in _years_, it's a very obscure thing, and odds are, it wouldn't >> > ever be added again, especially as it was just removed entirely not >> > being needed anymore. And I'd argue, it's something that you shouldn't >> > have even been doing in the first place, so why a new user of it was >> > added now is quite strange to me. >> >> Actually that's a good question. Is there a better way for us than to >> use this API ? Essentially we use that because it's our understanding >> that it is what is needed for a sysfs file that can remove its parent >> directory from within a write() op. >> >> We followed the driver "remove" implementation as an example. >> >> The reason the opal elog and dump patches use it is that those two >> patches add sysfs interface that represent the error logs (and platform >> dumps but you can treat the latter as some kind of special case of error >> logs) from the service processor in sysfs. >> >> So for each log we create a dir (kobject) which we populate with a few >> things like the log unique ID, raw data, etc and a file that can be >> used to "ack" the log with the service processor. >> >> The latter has the effect of removing it. This is done by the collection >> daemon after it has confirmed that the error log has been stored to disk >> and properly flushed. >> >> Is there a better interface ? Can we implement for example unlink() on >> the kobject itself ? IE. Do the ack by essentially having userspace rm >> the directory ? :-) > > No you can't, sorry. > > And this seems like a huge abuse of sysfs, you better be using binary > sysfs files for your log data... We are. It's a binary format we get from the service processor that we then parse in userspace. Seeing as each of these log entries is a separate thing that can be retrieved and acknowledged to the service processor, it seemed fitting to have each of them exposed to userspace so that policy can be dictated there (acking them removes them from FSP and we have use cases for peeking at them) If there's a better way, I'd be interested in hearing it - it appeared to be relatively good fit for sysfs (no sysadmin overhead, busybox has enough utility to semi-meaningfully poke at it). > Do you have a pointer to where you document this sysfs api in > Documentation/ABI/ ? Yes: - Documentation/ABI/stable/sysfs-firmware-opal-dump - Documentation/ABI/stable/sysfs-firmware-opal-elog >> Now regarding the practicals of sorting out our trees, Stephen suggested >> that rather than doing anything on my side (heh, I like that !), you >> should revert the last patch of the series, the one removing the old >> API, in your tree. >> >> It can then be re-applied later around rc1. > > I'll look to see if we can do that, let me dig it up out of my tree... Thanks. The new API looks like it should work fine for us, I'll be sure to covert my API usage and let you know. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] net: cdc_ncm: respect operator preferred MTU reported by MBIM
According to "Universal Serial Bus Communications Class Subclass
Specification for Mobile Broadband Interface Model, Revision 1.0,
Errata-1" published by USB-IF, the wMTU field of the MBIM extended
functional descriptor indicates the operator preferred MTU for IP data
streams.
This patch modifies cdc_ncm_setup to ensure that the MTU value set on
the usbnet device does not exceed the operator preferred MTU indicated
by wMTU if the MBIM device exposes a MBIM extended functional
descriptor.
Signed-off-by: Ben Chan
---
Patch v2 adds the le16_to_cpu conversion on ctx->mbim_extended_desc->wMTU as
pointed out and suggested by 'Bjørn Mork '.
drivers/net/usb/cdc_ncm.c | 17 +
include/linux/usb/cdc_ncm.h | 1 +
2 files changed, 18 insertions(+)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index dbff290..e8711a8 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -74,6 +74,7 @@ static int cdc_ncm_setup(struct usbnet *dev)
u8 iface_no;
int err;
int eth_hlen;
+ u16 mbim_mtu;
u16 ntb_fmt_supported;
__le16 max_datagram_size;
@@ -261,6 +262,14 @@ out:
/* set MTU to max supported by the device if necessary */
if (dev->net->mtu > ctx->max_datagram_size - eth_hlen)
dev->net->mtu = ctx->max_datagram_size - eth_hlen;
+
+ /* do not exceed operater preferred MTU */
+ if (ctx->mbim_extended_desc) {
+ mbim_mtu = le16_to_cpu(ctx->mbim_extended_desc->wMTU);
+ if (mbim_mtu != 0 && mbim_mtu < dev->net->mtu)
+ dev->net->mtu = mbim_mtu;
+ }
+
return 0;
}
@@ -399,6 +408,14 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct
usb_interface *intf, u8 data_
ctx->mbim_desc = (const struct usb_cdc_mbim_desc *)buf;
break;
+ case USB_CDC_MBIM_EXTENDED_TYPE:
+ if (buf[0] < sizeof(*(ctx->mbim_extended_desc)))
+ break;
+
+ ctx->mbim_extended_desc =
+ (const struct usb_cdc_mbim_extended_desc *)buf;
+ break;
+
default:
break;
}
diff --git a/include/linux/usb/cdc_ncm.h b/include/linux/usb/cdc_ncm.h
index c3fa807..bdf05fb 100644
--- a/include/linux/usb/cdc_ncm.h
+++ b/include/linux/usb/cdc_ncm.h
@@ -93,6 +93,7 @@ struct cdc_ncm_ctx {
const struct usb_cdc_ncm_desc *func_desc;
const struct usb_cdc_mbim_desc *mbim_desc;
+ const struct usb_cdc_mbim_extended_desc *mbim_extended_desc;
const struct usb_cdc_ether_desc *ether_desc;
struct usb_interface *control;
--
1.9.0.279.gdc9e3eb
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] uprobes: Add uprobes support for ARM
On Tue, Mar 11, 2014 at 02:36:09PM -0400, David Long wrote: > git://git.linaro.org/people/dave.long/linux.git uprobes-v7 > > for you to fetch changes up to e55c35236b8adf79453a998506ec6081833b9484: > > ARM: add uprobes support (2014-03-11 11:40:29 -0400) I pulled this a week ago into my devel-testing (which is unpublished), and while it hasn't shown any signs of functional problems, I was just about to merge it into devel-stable when I noticed the history. This is based upon: Merge branch 'for-next' of git://git.samba.org/sfrench/cifs-2.6 + Linux 3.11 + Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip + Linux 3.12-rc5 + Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net + Linux 3.13-rc3 + Linux 3.13-rc4 + Linux 3.13-rc8 + Linux 3.14-rc2 + Linux 3.14-rc4 + Linux 3.14-rc5 | [your uprobes patches] where each + is a merge of the named commit into the previous. This is the kind of thing which will make Linus quite unhappy: please base patches off a plain -rc release, not off a merge commit. I'm sure there's others on the mailing list who can guide you on this point, but I do need to ask you to re-spin without those merges. I'm happy to take a respin of it provided it's based on 3.14-rc5 (so I can more easily confirm that there aren't any changes which I haven't already tested.) Thanks, and sorry about the lateness of this email. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bisected] e501 "agp: Support 64-bit APBASE" agp fails without iommu=remap=2
[+cc Daniel, Dave, Yinghai, Guo, Aaron, LKML]
On Sat, Mar 15, 2014 at 02:32:22PM +0200, Jouni Mettälä wrote:
> Hi. I can't start xsession without iommu=remap=2 kernel parameter.
>
> Kernel bisect lead to this commit
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e501b3d87f003dfad8fcbd0f55ae17ea52495a56
>
> Reverting e501b3d87f003dfad8fcbd0f55ae17ea52495a56 fixes if for me.
>
> I think this is relevant part of dmesg from affected kernel
>
> agpgart-amd64 :00:04.0: AGP bridge [10b9/1689]
> agpgart-amd64 :00:04.0: aperture from AGP @ 0 size 4096 MB
> pci :00:18.3: no usable aperture found
> pci :00:18.3: consider rebooting with iommu=memaper=2 to get a good
> aperture
> agpgart-amd64 :00:04.0: AGP bridge [10b9/1689]
> agpgart-amd64 :00:04.0: aperture from AGP @ 0 size 4096 MB
> pci :00:18.3: no usable aperture found
> pci :00:18.3: consider rebooting with iommu=memaper=2 to get a good
> aperture
> agpgart-amd64 :04:00.0: AGP bridge [1002/4150]
> agpgart-amd64 :04:00.0: aperture size 4096 MB is not right, using
> settings from NB
> agpgart-amd64 :04:00.0: AGP aperture is 256M @ 0xa000
Jouni also opened this bug report with complete dmesg logs:
https://bugzilla.kernel.org/show_bug.cgi?id=72201
This is a regression that appeared in v3.14-rc1, when we merged
e501b3d87f00. The relevant part of that change is this:
--- a/drivers/char/agp/amd64-agp.c
+++ b/drivers/char/agp/amd64-agp.c
@@ -295,9 +294,7 @@ static int fix_northbridge(struct pci_dev *nb, struct
pci_dev *agp, u16 cap)
- pci_read_config_dword(agp, 0x10, _low);
- pci_read_config_dword(agp, 0x14, _hi);
- aper = (aper_low & ~((1<<22)-1)) | ((u64)aper_hi << 32);
+ aper = pci_bus_address(agp, AGP_APERTURE_BAR);
Here's what I think is happening: Previously, we read the GART
aperture base directly from the BAR. After e501b3d87f00, we use
pci_bus_address() to convert the aperture *resource* (which the PCI
core has previously read from the BAR and converted to a CPU address)
back into a bus address.
Normally both ways would give the same result, but here we had this:
Node 0: aperture @ a000 size 256 MB
pci :00:04.0: reg 0x10: [mem 0xa000-0xafff pref]
pci :00:04.0: address space collision: [mem 0xa000-0xafff pref]
conflicts with GART [mem 0xa000-0xafff]
The "Node 0" line is where we inserted the "GART [mem 0xa000-
0xafff]" resource in gart_iommu_hole_init(). Then we enumerated
the northbridge, which had a BAR containing 0xa000. When we tried
to claim that BAR, it conflicted with the "GART" resource, and we set
r->start = 0 (in pcibios_allocate_dev_resources()). So when we
finally got to fix_northbridge(), the aperture resource was set to
zero, not 0xa000.
Note that we complained about the collision even before e501b3d87f00.
The only difference is that we used to re-read the BAR, where we still
got 0xa000 even though the PCI core thought the resource was
invalid and had set it to zero.
I think we should stop inserting the GART resource directly in
iomem_resource in gart_iommu_hole_init(). That should avoid the
collision and leave the BAR resource valid, which means
pci_bus_address() should work.
Jouni, could you try the patch below?
Bjorn
Revert "[PATCH] Insert GART region into resource map"
From: Bjorn Helgaas
This reverts commit 56dd669a138c, which makes the GART visible in
/proc/iomem.
The GART addresses are bus addresses, not CPU addresses, and therefore
should not be inserted in iomem_resource.
On many machines, the GART region is addressable by the CPU as well as by
an AGP master, but CPU addressability is not required by the spec. On some
of these machines, the GART is mapped by a PCI BAR, and in that case, the
PCI core automatically inserts it into iomem_resource, just as it does for
all BARs.
Inserting it here means we'll have a conflict if the PCI core later tries
to claim the GART region.
Conflicts:
arch/x86_64/kernel/aperture.c
Signed-off-by: Bjorn Helgaas
---
arch/x86/kernel/aperture_64.c | 20 +---
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
index fd972a3e4cbb..9fa8aa051f54 100644
--- a/arch/x86/kernel/aperture_64.c
+++ b/arch/x86/kernel/aperture_64.c
@@ -18,7 +18,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -54,18 +53,6 @@ int fallback_aper_force __initdata;
int fix_aperture __initdata = 1;
-static struct resource gart_resource = {
- .name = "GART",
- .flags = IORESOURCE_MEM,
-};
-
-static void __init insert_aperture_resource(u32 aper_base, u32 aper_size)
-{
- gart_resource.start = aper_base;
- gart_resource.end = aper_base + aper_size - 1;
- insert_resource(_resource, _resource);
-}
-
/* This code runs before the PCI subsystem is
[PATCH] Fix late crypto work queue initialization
The crypto algorithm modules utilizing the crypto daemon could
be used early when the system start up. Using module_init
does not guarantee that the daemon's work queue is initialized
when the cypto alorithm depending on crypto_wq starts. It is necessary
to initialize the crypto work queue earlier at the subsystem
init time to make sure that it is initialized
when used.
Signed-off-by: Tim Chen
---
crypto/crypto_wq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/crypto_wq.c b/crypto/crypto_wq.c
index adad92a..2f1b8d1 100644
--- a/crypto/crypto_wq.c
+++ b/crypto/crypto_wq.c
@@ -33,7 +33,7 @@ static void __exit crypto_wq_exit(void)
destroy_workqueue(kcrypto_wq);
}
-module_init(crypto_wq_init);
+subsys_initcall(crypto_wq_init);
module_exit(crypto_wq_exit);
MODULE_LICENSE("GPL");
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 0/7] omap hwspinlock dt support
Hi Ohad, On 03/17/2014 02:47 PM, Ohad Ben-Cohen wrote: > Hi Suman, > > On Mon, Mar 17, 2014 at 9:10 PM, Suman Anna wrote: >> base_id would be a property (if added) of the hwspinlock controller node, >> and from DT perspective, we will be using the phandle for the controller >> anyway. So, using a base_id+specifier seems redundant, as the specifier is >> already w.r.t a hwspinlock controller node. It is best to leave the base_id >> out, just use the specifier. This is pretty much the standard practice >> (GPIOs, DMAs, etc all follow this). > > Do you mean hwspin_lock_get_id() will return just the specifier > instead of base_id+specifier? This is problematic, because Linux will > not be able to communicate this lock id outside to a different core > running a different OS: that OS will have no idea what hwlock > controller this is relative to. The behavior of hwspin_lock_get_id() is unchanged, so you will still get the global lock id back. The hwspin_lock_request_specific() (note: not the OF one) will also still be operating on the global lock id. > >> Please see the comments from Mark regarding the same on an earlier version. > > I think I understand and agree with Mark generally, but in this case, > the hwlock id is not an implementation detail. Unlike GPIOs/DMAs, this > id number is global and system-wide (Linux is just one component in > the system, and must use the same predefined id numbers all other > cores use, otherwise it will be impossible to use those hwlocks for > multi-core synchronization). > >> Yes, I agree this is an issue if we have to have the base_ids fixed per >> controller. > > Do you see any other way this could work if the base_ids were not > predefined? Linux and some other core running a different OS must > agree on the id numbers of the hardware locks we have in the system. So far, we have not come across multiple controllers. I see your point, and I think this also depends on the semantics of how you exchange the lock id number. The agreement at the moment is on base_ids across multiple SoC components. If the semantics involve exchanging the controller instance, for example, then we might get away with it. But that probably involves adding additional helpers to retrieve controller instance in addition to lock number, or some other similar functions. I can add back the hwlock-base-id binding to the controller node. Mark, Kumar, Do you have any issues adding back this element for registration purposes? > >>> Before DT came along, early board code could have reserved specific >>> hwspinlocks if needed. Now with DT, we should add the list of reserved >>> locks to the controller node, in order to prevent them from being >>> dynamically allocated by others. >> >> >> But that strictly relied on the order of requests without any core changes >> in the hwspinlock core, right. > > I don't think so, you could request a specific lock by id number. Sorry, I should have rephrased it better - by order, I meant the inherent order between board early code and other drivers. With DT, we cannot guarantee that right, as specific locks are requested from drivers. > >> With DT, the early board code is much simplified. Looking at the same >> scenario from DT case, it seems kinda redundant to specify a set of reserved >> locks both in the controller node, as well as the respective client drivers, >> as there is almost no platform data with DT. The only use case for DT client >> nodes would be for requesting specific locks. I agree with the problem you >> described, and I think it will require a different set of changes to the >> core. > > Exactly. The platform-specific hwspinlock driver will have to inform > the core, upon registration, which of the locks are already reserved. > In turn, the core will never provide them to clients that dynamically > allocate an hwlock: they will be provided only to clients that ask for > them specifically (using phandle+specifier). Understood. And we may have to assign the client association with a lock as well. These are core changes that were actually not needed in the non-DT case due to the inherent order as stated above. So, are you suggesting that we add one more property to the controller node to mark which are reserved, or rely on constructing this through DT tree parsing? regards Suman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
Hi Philipp, On Friday 14 March 2014 13:19:39 Philipp Zabel wrote: > Am Donnerstag, den 13.03.2014, 18:13 +0100 schrieb Laurent Pinchart: > > On Thursday 13 March 2014 12:08:16 Philipp Zabel wrote: > > > Am Montag, den 10.03.2014, 14:37 + schrieb Grant Likely: > > > > > > Nak. I made comments that haven't been resolved yet. I've replied > > > > > > with more detail tonight. The big issues are how drivers handle > > > > > > the optional 'ports' node and I do not agree to the double-linkage > > > > > > in the binding description. > > > > > > so as I understand it, nobody is against dropping the double-linkage > > > *if* we can agree on a way to recreate the backlinks in the kernel. > > > > I'm not sure about "nobody", but even though it might not be my favorite > > option I'd be OK with that. > > Ok, I make that assumption going by the discussion about link direction that > ensued. > > > > My current suggestion would be to parse the complete device tree into an > > > internal graph structure once, at boot to achieve this. This code could > > > look for the optional 'ports' node if and only if the parent device node > > > contains #address-cells != <1> or #size-cells != <0> properties. > > > > With backlinks in DT we can assume that, if a node is the target of a > > link, it will be compatible with the of-graph bindings, and thus parse > > the node to locate other ports and other links. This allows parsing the > > full graph without help of individual drivers. > > Yes. > > > Without backlinks in DT we need to parse the full DT to reconstruct > > backlinks in the kernel. One possible issue with that is that we can't > > know whether a node implements the of-graph bindings. We can use the > > heuristic you've described above, but I wonder if it could lead to > > problems. Grant pointed out that the compatibility string defines what > > binding a node uses, and that we can't thus look for properties randomly. > > I don't think there's a risk to interpret an unrelated node as part of a > > graph though. > > False positives would just take up a bit of space in the endpoint lists, but > otherwise should be no problem, as they would only be used when either a > driver implementing the bindings is bound, or when they are connected to > other endpoints. Whether or not we scan the whole tree, using this > heuristic, is more a matter of principle. That is my understanding as well, so we should be good there. > > > People completely disagree about the direction the phandle links should > > > point in. I am still of the opinion that the generic binding should > > > describe just the topology, that the endpoint links in the kernel > > > should represent an undirected graph and the direction of links should > > > not matter at all for the generic graph bindings. > > > > I would also not mandate a specific direction at the of-graph level and > > leave it to subsystems (or possibly drivers) to specify the direction. > > Thank you. Can everybody live with this? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/4] x86, random: Enable the RDSEED instruction
Upcoming Intel silicon adds a new RDSEED instruction, which is similar
to RDRAND but provides a stronger guarantee: unlike RDRAND, RDSEED
will always reseed the PRNG from the true random number source between
each read. Thus, the output of RDSEED is guaranteed to be 100%
entropic, unlike RDRAND which is only architecturally guaranteed to be
1/512 entropic (although in practice is much more.)
The RDSEED instruction takes the same time to execute as RDRAND, but
RDSEED unlike RDRAND can legitimately return failure (CF=0) due to
entropy exhaustion if too many threads on too many cores are hammering
the RDSEED instruction at the same time. Therefore, we have to be
more conservative and only use it in places where we can tolerate
failures.
This patch introduces the primitives arch_get_random_seed_{int,long}()
but does not use it yet.
Signed-off-by: H. Peter Anvin
Reviewed-by: Ingo Molnar
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
---
arch/powerpc/include/asm/archrandom.h | 9 +
arch/x86/include/asm/archrandom.h | 34 +-
include/linux/random.h| 8
3 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/archrandom.h
b/arch/powerpc/include/asm/archrandom.h
index d853d16..801beba 100644
--- a/arch/powerpc/include/asm/archrandom.h
+++ b/arch/powerpc/include/asm/archrandom.h
@@ -27,6 +27,15 @@ static inline int arch_get_random_int(unsigned int *v)
int powernv_get_random_long(unsigned long *v);
+static inline int arch_get_random_seed_long(unsigned long *v)
+{
+ return 0;
+}
+static inline int arch_get_random_seed_int(unsigned int *v)
+{
+ return 0;
+}
+
#endif /* CONFIG_ARCH_RANDOM */
#endif /* _ASM_POWERPC_ARCHRANDOM_H */
diff --git a/arch/x86/include/asm/archrandom.h
b/arch/x86/include/asm/archrandom.h
index 0d9ec77..ba064d5 100644
--- a/arch/x86/include/asm/archrandom.h
+++ b/arch/x86/include/asm/archrandom.h
@@ -1,7 +1,7 @@
/*
* This file is part of the Linux kernel.
*
- * Copyright (c) 2011, Intel Corporation
+ * Copyright (c) 2011-2014, Intel Corporation
* Authors: Fenghua Yu ,
* H. Peter Anvin
*
@@ -31,14 +31,27 @@
#define RDRAND_RETRY_LOOPS 10
#define RDRAND_INT ".byte 0x0f,0xc7,0xf0"
+#define RDSEED_INT ".byte 0x0f,0xc7,0xf8"
#ifdef CONFIG_X86_64
# define RDRAND_LONG ".byte 0x48,0x0f,0xc7,0xf0"
+# define RDSEED_LONG ".byte 0x48,0x0f,0xc7,0xf8"
#else
# define RDRAND_LONG RDRAND_INT
+# define RDSEED_LONG RDSEED_INT
#endif
#ifdef CONFIG_ARCH_RANDOM
+/* A single attempt at RDSEED */
+static inline bool rdseed_long(unsigned long *v)
+{
+ unsigned char ok;
+ asm volatile(RDSEED_LONG "\n\t"
+"setc %0"
+: "=qm" (ok), "=a" (*v));
+ return ok;
+}
+
#define GET_RANDOM(name, type, rdrand, nop)\
static inline int name(type *v)\
{ \
@@ -56,16 +69,35 @@ static inline int name(type *v)
\
return ok; \
}
+#define GET_SEED(name, type, rdseed, nop) \
+static inline int name(type *v)\
+{ \
+ unsigned char ok; \
+ alternative_io("movb $0, %0\n\t"\
+ nop, \
+ rdseed "\n\t"\
+ "setc %0", \
+ X86_FEATURE_RDSEED, \
+ ASM_OUTPUT2("=q" (ok), "=a" (*v))); \
+ return ok; \
+}
+
#ifdef CONFIG_X86_64
GET_RANDOM(arch_get_random_long, unsigned long, RDRAND_LONG, ASM_NOP5);
GET_RANDOM(arch_get_random_int, unsigned int, RDRAND_INT, ASM_NOP4);
+GET_SEED(arch_get_random_seed_long, unsigned long, RDSEED_LONG, ASM_NOP5);
+GET_SEED(arch_get_random_seed_int, unsigned int, RDSEED_INT, ASM_NOP4);
+
#else
GET_RANDOM(arch_get_random_long, unsigned long, RDRAND_LONG, ASM_NOP3);
GET_RANDOM(arch_get_random_int, unsigned int, RDRAND_INT, ASM_NOP3);
+GET_SEED(arch_get_random_seed_long, unsigned long, RDSEED_LONG, ASM_NOP4);
+GET_SEED(arch_get_random_seed_int, unsigned int, RDSEED_INT, ASM_NOP4);
+
#endif /* CONFIG_X86_64 */
#endif /* CONFIG_ARCH_RANDOM */
diff --git a/include/linux/random.h b/include/linux/random.h
index 4002b3d..ddaddec 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -72,6 +72,14 @@ static inline int arch_get_random_int(unsigned int *v)
{
return 0;
}
+static inline int arch_get_random_seed_long(unsigned long *v)
+{
+ return 0;
+}
+static
[PATCH v2 4/4] random: Add arch_has_random[_seed]()
Add predicate functions for having arch_get_random[_seed]*(). The
only current use is to avoid the loop in arch_random_refill() when
arch_get_random_seed_long() is unavailable.
Signed-off-by: H. Peter Anvin
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
---
arch/powerpc/include/asm/archrandom.h | 9 +
arch/x86/include/asm/archrandom.h | 3 +++
drivers/char/random.c | 3 +++
include/linux/random.h| 8
4 files changed, 23 insertions(+)
diff --git a/arch/powerpc/include/asm/archrandom.h
b/arch/powerpc/include/asm/archrandom.h
index 801beba..bde5311 100644
--- a/arch/powerpc/include/asm/archrandom.h
+++ b/arch/powerpc/include/asm/archrandom.h
@@ -25,6 +25,11 @@ static inline int arch_get_random_int(unsigned int *v)
return rc;
}
+static inline int arch_has_random(void)
+{
+ return !!ppc_md.get_random_long;
+}
+
int powernv_get_random_long(unsigned long *v);
static inline int arch_get_random_seed_long(unsigned long *v)
@@ -35,6 +40,10 @@ static inline int arch_get_random_seed_int(unsigned int *v)
{
return 0;
}
+static inline int arch_has_random_seed(void)
+{
+ return 0;
+}
#endif /* CONFIG_ARCH_RANDOM */
diff --git a/arch/x86/include/asm/archrandom.h
b/arch/x86/include/asm/archrandom.h
index ba064d5..c7ed4a6 100644
--- a/arch/x86/include/asm/archrandom.h
+++ b/arch/x86/include/asm/archrandom.h
@@ -100,6 +100,9 @@ GET_SEED(arch_get_random_seed_int, unsigned int,
RDSEED_INT, ASM_NOP4);
#endif /* CONFIG_X86_64 */
+#define arch_has_random() static_cpu_has(X86_FEATURE_RDRAND)
+#define arch_has_random_seed() static_cpu_has(X86_FEATURE_RDSEED)
+
#endif /* CONFIG_ARCH_RANDOM */
extern void x86_init_rdrand(struct cpuinfo_x86 *c);
diff --git a/drivers/char/random.c b/drivers/char/random.c
index c35cee2..6b75713 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1307,6 +1307,9 @@ static int arch_random_refill(void)
unsigned int i;
unsigned long buf[nlongs];
+ if (!arch_has_random_seed())
+ return 0;
+
for (i = 0; i < nlongs; i++) {
if (arch_get_random_seed_long([n]))
n++;
diff --git a/include/linux/random.h b/include/linux/random.h
index ddaddec..e7a221a 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -72,6 +72,10 @@ static inline int arch_get_random_int(unsigned int *v)
{
return 0;
}
+static inline int arch_has_random(void)
+{
+ return 0;
+}
static inline int arch_get_random_seed_long(unsigned long *v)
{
return 0;
@@ -80,6 +84,10 @@ static inline int arch_get_random_seed_int(unsigned int *v)
{
return 0;
}
+static inline int arch_has_random_seed(void)
+{
+ return 0;
+}
#endif
/* Pseudo random number generator from numerical recipes. */
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/4] random: Use arch_get_random_seed*() at init time and once a second
Use arch_get_random_seed*() in two places in the Linux random
driver (drivers/char/random.c):
1. During entropy pool initialization, use RDSEED in favor of RDRAND,
with a fallback to the latter. Entropy exhaustion is unlikely to
happen there on physical hardware as the machine is single-threaded
at that point, but could happen in a virtual machine. In that
case, the fallback to RDRAND will still provide more than adequate
entropy pool initialization.
2. Once a second, issue RDSEED and, if successful, feed it to the
entropy pool. To ensure an extra layer of security, only credit
half the entropy just in case.
Suggested-by: Linus Torvalds
Reviewed-by: Ingo Molnar
Signed-off-by: H. Peter Anvin
---
drivers/char/random.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index d07575c..a4bea77 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -844,6 +844,8 @@ void add_interrupt_randomness(int irq, int irq_flags)
cycles_tcycles = random_get_entropy();
__u32 input[4], c_high, j_high;
__u64 ip;
+ unsigned long seed;
+ int credit;
c_high = (sizeof(cycles) > 4) ? cycles >> 32 : 0;
j_high = (sizeof(now) > 4) ? now >> 32 : 0;
@@ -862,20 +864,33 @@ void add_interrupt_randomness(int irq, int irq_flags)
r = nonblocking_pool.initialized ? _pool : _pool;
__mix_pool_bytes(r, _pool->pool, sizeof(fast_pool->pool), NULL);
+
/*
* If we don't have a valid cycle counter, and we see
* back-to-back timer interrupts, then skip giving credit for
-* any entropy.
+* any entropy, otherwise credit 1 bit.
*/
+ credit = 1;
if (cycles == 0) {
if (irq_flags & __IRQF_TIMER) {
if (fast_pool->last_timer_intr)
- return;
+ credit = 0;
fast_pool->last_timer_intr = 1;
} else
fast_pool->last_timer_intr = 0;
}
- credit_entropy_bits(r, 1);
+
+ /*
+* If we have architectural seed generator, produce a seed and
+* add it to the pool. For the sake of paranoia count it as
+* 50% entropic.
+*/
+ if (arch_get_random_seed_long()) {
+ __mix_pool_bytes(r, , sizeof(seed), NULL);
+ credit += sizeof(seed) * 4;
+ }
+
+ credit_entropy_bits(r, credit);
}
#ifdef CONFIG_BLOCK
@@ -1235,7 +1250,8 @@ static void init_std_data(struct entropy_store *r)
r->last_pulled = jiffies;
mix_pool_bytes(r, , sizeof(now), NULL);
for (i = r->poolinfo->poolbytes; i > 0; i -= sizeof(rv)) {
- if (!arch_get_random_long())
+ if (!arch_get_random_seed_long() &&
+ !arch_get_random_long())
rv = random_get_entropy();
mix_pool_bytes(r, , sizeof(rv), NULL);
}
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] random: If we have arch_get_random_seed*(), try it before blocking
If we have arch_get_random_seed*(), try to use it for emergency refill
of the entropy pool before giving up and blocking on /dev/random. It
may or may not work in the moment, but if it does work, it will give
the user better service than blocking will.
Reviewed-by: Ingo Molnar
Signed-off-by: H. Peter Anvin
---
drivers/char/random.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index a4bea77..c35cee2 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1294,6 +1294,34 @@ void rand_initialize_disk(struct gendisk *disk)
}
#endif
+/*
+ * Attempt an emergency refill using arch_get_random_seed_long().
+ *
+ * As with add_interrupt_randomness() be paranoid and only
+ * credit the output as 50% entropic.
+ */
+static int arch_random_refill(void)
+{
+ const unsigned int nlongs = 64; /* Arbitrary number */
+ unsigned int n = 0;
+ unsigned int i;
+ unsigned long buf[nlongs];
+
+ for (i = 0; i < nlongs; i++) {
+ if (arch_get_random_seed_long([n]))
+ n++;
+ }
+
+ if (n) {
+ unsigned int rand_bytes = n * sizeof(unsigned long);
+
+ mix_pool_bytes(_pool, buf, rand_bytes, NULL);
+ credit_entropy_bits(_pool, rand_bytes*4);
+ }
+
+ return n;
+}
+
static ssize_t
random_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
{
@@ -1312,8 +1340,13 @@ random_read(struct file *file, char __user *buf, size_t
nbytes, loff_t *ppos)
ENTROPY_BITS(_pool));
if (n > 0)
return n;
+
/* Pool is (near) empty. Maybe wait and retry. */
+ /* First try an emergency refill */
+ if (arch_random_refill())
+ continue;
+
if (file->f_flags & O_NONBLOCK)
return -EAGAIN;
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/4] RDSEED support for the Linux kernel
Upcoming Intel silicon adds a new RDSEED instruction. Whereas RDRAND returns output from a PRNG, the RDSEED instruction returns fully conditioned entropy that is suitable for use as seeds to a PRNG. This patchset adds support for RDSEED in the Linux kernel in three places: 1. During bootup, use RDSEED to initialize the entropy pool if available (we already use RDRAND for this). We don't add any credit at this point, but it will give much better starting point. 2. In the slow path to add_interrupt_randomness, executed once per second, we take a single RDSEED sample and mix it into the entropy pool, crediting it at 50% of its rated entropy. This was suggested by Linus. 3. If we are about to block on /dev/random due to lack of entropy, attempt an "emergency pool refill" using RDSEED. Changes since version 1: a. Rebased on top of random.git:dev. b. Unbreak the PowerPC build (I had managed to miss that PowerPC had grown archrandom.h support.) c. Remove duplicate dummy function definitions in . d. Add a fourth patch containing a microoptimization: avoid the loop in arch_random_refill() if arch_get_random_seed*() is unavailable. Comments are, of course, appreciated. Ted, if you are OK with this could you add this to random.git:dev so linux-next can pick it up? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mm: munlock: fix a bug where THP tail page is encountered
=6048768 [ 1753.911692] page:ea001713 count:2 mapcount:1 mapping:880612b41f01 index:0x7fa3a5200 [ 1753.912733] page flags: 0x16f80384028(uptodate|lru|head|swapbacked|unevictable|mlocked) [ 1753.913464] page dumped because: first_page of unexpected PageTail page [ 1753.914387] pc:88062adcc000 pc->flags:2 pc->mem_cgroup:88012b474520 [ 1753.914387] first_page is compound with order=9 [ 1753.914387] [ cut here ] [ 1753.914387] kernel BUG at mm/mlock.c:512! [ 1753.914387] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 1753.914387] Dumping ftrace buffer: [ 1753.914387](ftrace buffer empty) [ 1753.914387] Modules linked in: [ 1753.914387] CPU: 26 PID: 36822 Comm: trinity-c337 Tainted: G W 3.14.0-rc6-next-20140317-sasha-00012-ge933921-dirty #226 [ 1753.914387] task: 88090cdeb000 ti: 88090a868000 task.ti: 88090a868000 [ 1753.914387] RIP: 0010:[] [] munlock_vma_pages_range+0x12a/0x340 [ 1753.914387] RSP: 0018:88090a869dd8 EFLAGS: 00010292 [ 1753.914387] RAX: 0023 RBX: ea001713 RCX: 0006 [ 1753.914387] RDX: 0006 RSI: 88090cdebcf0 RDI: 0282 [ 1753.914387] RBP: 88090a869ec8 R08: 0001 R09: 0001 [ 1753.914387] R10: 0001 R11: 0001 R12: 7fa3a5231000 [ 1753.914387] R13: 880613c69400 R14: 1600 R15: [ 1753.914387] FS: 7fa3a9081700() GS:880b2ba0() knlGS: [ 1753.914387] CS: 0010 DS: ES: CR0: 8005003b [ 1753.914387] CR2: 02fff0a8 CR3: 0008fa08d000 CR4: 06a0 [ 1753.914387] Stack: [ 1753.914387] 7fa3a5232000 48200176 7fa3a552a000 880613c6a800 [ 1753.914387] 7fa3a552a000 7fa3a5231000 [ 1753.914387] 000188090a869e38 880613c69400 [ 1753.914387] Call Trace: [ 1753.914387] [] do_munmap+0x1d2/0x360 [ 1753.914387] [] ? down_write+0xa6/0xc0 [ 1753.914387] [] ? vm_munmap+0x46/0x80 [ 1753.914387] [] vm_munmap+0x54/0x80 [ 1753.914387] [] SyS_munmap+0x2c/0x40 [ 1753.914387] [] tracesys+0xdd/0xe2 [ 1753.914387] Code: 85 48 89 df e8 98 d0 fc ff 66 f7 03 00 c0 74 1b 48 8b 03 31 f6 f6 c4 40 74 03 8b 73 68 48 c7 c7 58 7d 6e 85 31 c0 e8 52 1f 20 03 <0f> 0b 0f 1f 40 00 eb fe 66 0f 1f 44 00 00 48 8b 03 66 85 c0 79 [ 1753.914387] RIP [] munlock_vma_pages_range+0x12a/0x340 [ 1753.914387] RSP Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
Hi Robert, On Friday 14 March 2014 08:05:05 Robert Schwebel wrote: > On Thu, Mar 13, 2014 at 04:13:08PM +0100, Sylwester Nawrocki wrote: > > My experience and feelings are similar, I started to treat mainline > > kernel much less seriously after similar DT related blocking issues. > > So how do we proceed now? Philipp implemented any of the suggested variants > now; nevertheless, there doesn't seem to be a consensus. > > However, we really need a decision of the oftree maintainers. I think we are > fine with almost any of the available variants, as long as there is a > decision. > > It would be great if we could soon continue to address the technical issues > with the IPU, instead of turning around oftree bindings. There is really > enough complexity left :-) I agree with you. I know that DT bindings review takes too much time, slows development down and is just generally painful. I'm trying to reply to this e- mail thread as fast as possible, but I'm also busy with other tasks :-/ The lack of formal consensus comes partly from the fact that people are busy and that the mail thread is growing big. There's still two open questions from my view of the whole discussion: - Do we really want to drop bidirectional links ? Grant has been pretty vocal about that, but there has been several replies with arguments for bidirectional links, and no reply from him afterwards. Even though that wouldn't be the preferred solution for everybody, there doesn't seem to be a strong disagreement about dropping bidirectional links, as long as we can come up with a reasonable implementation. - If we drop bidirectional links, what link direction do we use ? There has been several proposals (including "north", which I think isn't future-proof as it assumes an earth-centric model) and no real agreement, although there seems to be a consensus among several developers that the core OF graph bindings could leave that to be specified by subsystem bindings. We would still have to agree on a direction for the display subsystem of course. If my above explanation isn't too far from the reality the next step could be to send a new version of the DT bindings proposal as a ping. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] staging: cxtie1: remove unneeded mkret() calls
Ok. I will rebase this patch in staging-next branch and send it again. Thanks. Daeseok Youn. 2014-03-18 6:23 GMT+09:00 Greg KH : > On Mon, Mar 10, 2014 at 08:54:18AM +0900, Daeseok Youn wrote: >> >> The mkret() change a value of error from positive to >> negative. This patch is modified to return negative value >> when it failed. It doesn't need to call with function >> for changing from positive to negative. >> >> Signed-off-by: Daeseok Youn >> --- >> drivers/staging/cxt1e1/linux.c | 72 >> +-- >> drivers/staging/cxt1e1/musycc.c|2 +- >> drivers/staging/cxt1e1/pmcc4_drv.c | 40 ++-- >> 3 files changed, 48 insertions(+), 66 deletions(-) > > This patch no longer applies to my tree, can you refresh it and resend? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] uio: Fix memory size check with vma in uio_mmap_physical()
On Wed, Mar 12, 2014 at 10:24:21AM +0900, Nobuhiro Iwamatsu wrote: > Register for the device are mapped in uio_mmap_physical(). > In this case, it might not be the same as the size of VMA always. Why wouldn't this be the case? > This uses PAGE_ALIGN to memory size, fix the check of the memory size > to be mapped. > > Signed-off-by: Nobuhiro Iwamatsu > --- > drivers/uio/uio.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c > index a673e5b..e371f5a 100644 > --- a/drivers/uio/uio.c > +++ b/drivers/uio/uio.c > @@ -655,7 +655,7 @@ static int uio_mmap_physical(struct vm_area_struct *vma) > > if (mem->addr & ~PAGE_MASK) > return -ENODEV; > - if (vma->vm_end - vma->vm_start > mem->size) > + if (vma->vm_end - vma->vm_start > PAGE_ALIGN(mem->size)) You just increased the size for the check, that seems wrong. Why wouldn't mem->size be correct here? What hardware is failing for this with a valid size and end/start addresses? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v3.13][v3.14][Regression] kthread: make kthread_create() killable
> Root cause time: it's wrong for the oom-killer to use SIGKILL. In fact It has to use SIGKILL anything else might be caught and grow the user stack a page.. > it's basically always wrong to send signals from in-kernel. Signals > are a userspace IPC mechanism and using them in-kernel a) makes it hard > (or impossible) to distinguish them from userspace-originated signals Actually signals are a kernel messaging system someone repurposed for IPC. > and b) permits userspace to produce surprising results in the kernel, > which I suspect is what we're seeing here. There is enough information for kernel side code to decide whether a signal came from kernel or userspace. Then again - it's not clear that it should ever have to. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] md: Add support for RAID-1 consistency check feature
On Mon, 17 Mar 2014 16:00:05 +0100 Ralph Mueck wrote:
> This patch introduces a consistency check feature for level-1 RAID
> arrays that have been created with the md driver.
> When enabled, every read request is duplicated and initiated for each
> member of the RAID array. All read blocks are compared with their
> corresponding blocks on the other array members. If the check fails for
> a block, the block is not handed over, but an error code is returned
> instead.
> As mentioned in the cover letter, the implementation still has some
> unresolved issues.
>
> Signed-off-by: Ralph Mueck
> Signed-off-by: Matthias Oefelein
>
> ---
> drivers/md/raid1.c | 252
> -
> 1 file changed, 250 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index 4a6ca1c..8c64f9a 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -37,6 +37,7 @@
> #include
> #include
> #include
> +#include
> #include "md.h"
> #include "raid1.h"
> #include "bitmap.h"
> @@ -257,6 +258,109 @@ static void call_bio_endio(struct r1bio *r1_bio)
> }
> }
>
> +/* The safe_read version of the raid_end_bio_io() function */
> +/* On a read request, we issue requests to all available disks.
> + * Data is returned only if all discs contain the same data
> + */
> +static void _endio(struct r1bio *r1_bio)
> +{
> + struct bio *bio = r1_bio->master_bio;
> + int done;
> + struct r1conf *conf = r1_bio->mddev->private;
> + sector_t start_next_window = r1_bio->start_next_window;
> + sector_t bi_sector = bio->bi_iter.bi_sector;
> + int disk;
> + struct md_rdev *rdev;
> + int i;
> + struct page *dragptr = NULL;
> + int already_copied = 0; /* we want to copy the data only once */
> +
> + for (disk = 0 ; disk < conf->raid_disks * 2 ; disk++) {
> + struct bio *p = NULL;
> + struct bio *s = NULL;
> +
> + rcu_read_lock();
> + rdev = rcu_dereference(conf->mirrors[disk].rdev);
> + rcu_read_unlock();
You cannot drop rcu_read_lock until you take a reference to rdev, or stop
using it.
> +
> + if (r1_bio->bios[disk] == IO_BLOCKED
> + || rdev == NULL
> + || test_bit(Unmerged, >flags)
> + || test_bit(Faulty, >flags)) {
> + continue;
> + }
> +
> + /* bio_for_each_segment is broken. at least here.. */
> + /* iterate over linked bios */
> + for (p = r1_bio->master_bio, s = r1_bio->bios[disk];
> + (p != NULL) && (s != NULL);
> + p = p->bi_next, s = s->bi_next) {
> + /* compare the pages read */
> + for (i = 0; i < r1_bio->bios[disk]->bi_vcnt; i++) {
> + if (dragptr) { /* dragptr points to the
> previous page */
> +
> if(memcmp(page_address(r1_bio->bios[disk]->bi_io_vec[0].bv_page),
> + page_address(dragptr),
> +
> (r1_bio->bios[disk]->bi_io_vec[0].bv_len))) {
> + set_bit(R1BIO_ReadError,
> _bio->state);
> + clear_bit(R1BIO_Uptodate,
> _bio->state);
> + }
> + }
> + dragptr =
> r1_bio->bios[disk]->bi_io_vec[0].bv_page;
> + }
This doesn't make any sense to me at all. You use 'i' to loop bi_vnt times,
but never use 'i' or change any other variable in that loop (except dragptr
which is always set to the same value).
And you use "bi_next", but next set up any linkage through bi_next.
Confused.
NeilBrown
signature.asc
Description: PGP signature
Re: [PATCH 1/2] USB: cdc: add MBIM extended functional descriptor structure
On Sat, Mar 15, 2014 at 11:49:09PM -0700, Ben Chan wrote: > This patch adds the MBIM extended functional descriptor structure > defined in "Universal Serial Bus Communications Class Subclass > Specification for Mobile Broadband Interface Model, Revision 1.0, > Errata-1" published by USB-IF. > > Signed-off-by: Ben Chan > --- > include/uapi/linux/usb/cdc.h | 12 > 1 file changed, 12 insertions(+) Acked-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: gadget: f_fs: add missing spinlock and mutex unlock
On Mon, Mar 17, 2014 at 04:04:04PM -0700, Greg KH wrote:
> On Mon, Mar 10, 2014 at 09:33:37AM +0100, Robert Baldyga wrote:
> > This patch adds missing spin_unlock and mutex_unlock calls in
> > error handling code.
> >
> > Signed-off-by: Robert Baldyga
> > Acked-by: Michal Nazarewicz
> > Acked-by: Felipe Balbi
> > ---
> > drivers/usb/gadget/f_fs.c |8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
> > index b7d273a..d6bd0a3 100644
> > --- a/drivers/usb/gadget/f_fs.c
> > +++ b/drivers/usb/gadget/f_fs.c
> > @@ -802,7 +802,7 @@ static ssize_t ffs_epfile_io(struct file *file, struct
> > ffs_io_data *io_data)
> > if (io_data->aio) {
> > req = usb_ep_alloc_request(ep->ep, GFP_KERNEL);
> > if (unlikely(!req))
> > - goto error;
> > + goto error_lock;
> >
> > req->buf = data;
> > req->length = io_data->len;
> > @@ -817,7 +817,7 @@ static ssize_t ffs_epfile_io(struct file *file, struct
> > ffs_io_data *io_data)
> > ret = usb_ep_queue(ep->ep, req, GFP_ATOMIC);
> > if (unlikely(ret)) {
> > usb_ep_free_request(ep->ep, req);
> > - goto error;
> > + goto error_lock;
> > }
> > ret = -EIOCBQUEUED;
> >
> > @@ -863,6 +863,10 @@ static ssize_t ffs_epfile_io(struct file *file, struct
> > ffs_io_data *io_data)
> >
> > mutex_unlock(>mutex);
> > return ret;
> > +
> > +error_lock:
> > + spin_unlock_irq(>ffs->eps_lock);
> > + mutex_unlock(>mutex);
> > error:
> > kfree(data);
> > return ret;
> > --
> > 1.7.9.5
>
> This patch doesn't apply to my tree at all :(
Ick, wrong tree, nevermind...
greg "too many kernel trees" k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
