Some older devices (most notably tapes) will only report reliable
information in page 0x80 (Unit Serial Number). So export this
in the sysfs attribute 'vpd_pg80'.
Cc: Doug Gilbert
Cc: Jeremy Linton
Signed-off-by: Hannes Reinecke
---
drivers/scsi/scsi.c| 27 ++-
EVPD page 0x83 is used to uniquely identify the device.
So instead of having each and every program issue a separate
SG_IO call to retrieve this information it does make far more
sense to display it in sysfs.
Cc: Jeremy Linton
Cc: Kay Sievers
Cc: Doug Gilbert
Cc: Kai Makisara
Signed-off-by: Ha
Here's now v9 of my patch series to display VPD pages
in sysfs.
Changes to v8:
- Fixed 'vpg' spelling error
- Moved to binary attributes
- Implement VPD page refreshing by either calling 'rescan'
or due to a SCSI sense event.
So with this series all outstanding issues should be resolved.
And eve
The scsi_device now has VPD page83 information attached, so
there is no need to query it again.
Signed-off-by: Hannes Reinecke
---
drivers/scsi/ses.c | 38 ++
1 file changed, 10 insertions(+), 28 deletions(-)
diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses
We should be returning the number of bytes of the
requested VPD page in scsi_vpd_inquiry.
This makes it easier for the caller to verify the
required space.
Signed-off-by: Hannes Reinecke
---
drivers/scsi/scsi.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git
Add a flag 'vpd_invalid' to the SCSI device to indicate that
the VPD data needs to be refreshed. This is required if either
a manual rescan is triggered or if the sense code INQUIRY DATA
HAS CHANGED has been received.
Signed-off-by: Hannes Reinecke
---
drivers/scsi/scsi.c| 91 +++
Instead of modifying attributes after the device has been created
we should be using the 'is_visible' callback to avoid races.
Signed-off-by: Hannes Reinecke
---
drivers/scsi/scsi_sysfs.c | 184 +++---
1 file changed, 93 insertions(+), 91 deletions(-)
dif
On Friday 14 March 2014, Loc Ho wrote:
> > I still think it's rather unlikely that we will actually see ACPI support
> > on your platform, btw.
> >
> > I'm willing to look at the patches you need for it, but I'm not very
> > optimistic, in particular because of the kind of hacks you need
> > for r
On Saturday 15 March 2014, Loc Ho wrote:
> This patch adds the DTS entries for the APM X-Gene SoC 15Gbps Multi-purpose
> PHY driver. The PHY for SATA controller 2 and 3 are enabled by default.
>
> Signed-off-by: Loc Ho
> Signed-off-by: Tuan Phan
> Signed-off-by: Suman Tripathi
Acked-by: Arnd B
On Saturday 15 March 2014, Loc Ho wrote:
> This patch adds documentation for the APM X-Gene SoC SATA host controller DTS
> binding.
>
> Signed-off-by: Loc Ho
> Signed-off-by: Tuan Phan
> Signed-off-by: Suman Tripathi
Acked-by: Arnd Bergmann
--
To unsubscribe from this list: send the line "uns
On Saturday 15 March 2014, Loc Ho wrote:
> This patch adds APM X-Gene SoC AHCI SATA host controller DTS entries.
>
> Signed-off-by: Loc Ho
> Signed-off-by: Tuan Phan
> Signed-off-by: Suman Tripathi
Acked-by: Arnd Bergmann
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi
On Saturday 15 March 2014, Loc Ho wrote:
> This patch adds support for the APM X-Gene SoC AHCI SATA host controller
> driver. It requires the corresponding APM X-Gene SoC PHY driver. This
> initial version only supports Gen3 speed.
This version seems workable, thanks for the quick follow-up.
The
The dev argument was removed, so don't pretend to document it.
Signed-off-by: Christoph Hellwig
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 843b4f1..2b12983 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -305,7 +305,6 @@ EXPORT_SYMBOL(scsi_get_command);
* __scsi
On Fri, Mar 14, 2014 at 12:21:11PM -0400, Mike Snitzer wrote:
> DM multipath has a role in insuring the desired scsi_dh is attached and
> that it holds a reference on the attached scsi_dh.
>
> I'm open to ideas of how dm-multipath could avoid having _any_ role here
> but it isn't so simple to avoi
On Fri, Mar 14, 2014 at 12:26:15PM -0400, Mike Snitzer wrote:
> On Fri, Mar 14 2014 at 12:21pm -0400,
> Mike Snitzer wrote:
>
> > I have no problem with this patch, added safety-net and all, but
> > bottomline: if scsi_dh interfaces were being called against a DM
> > multipath request_queue that
On Fri, Mar 14, 2014 at 10:13:01AM -0400, Mike Snitzer wrote:
> I was more reacting to the assertion you made like multipath regresses
> all the time. I'm not faulting you at all for not having tested
> multipath. Hell, I even forget to test multipath more than I should.
> /me says with shame
An
Tomas reports that mptsas can crash if probe is interrupted by a signal:
Tomas Cernaj wrote:
> Dear Maintainer,
>
> after upgrading from linux-image-3.12 to 3.13, systemd-udevd kills the mptsas
> module initialization during boot after 30 seconds while probing the SAS
> hardware. As a consequenc
This is a set of six fixes. Two are instant crash/null deref types
(storvsc and isci reset fixes). The two qla2xxx are initialisation
problems that cause MSI-X failures and card misdetection, the isci
erroneous macro is actually illegal C that's causing a miscompile with
certain gcc versions and t
On Fri, 2014-03-14 at 13:11 -0700, Dan Williams wrote:
> On Mon, Mar 10, 2014 at 11:29 PM, James Bottomley
> wrote:
> >> > In the long game, though this whole debate is moot: setups with hard
> >> > wired start times adhere to them regardless of what the system does, so
> >> > they ignore start un
On Sat, Mar 15, 2014 at 2:47 PM, James Bottomley
wrote:
> On Fri, 2014-03-14 at 13:11 -0700, Dan Williams wrote:
>> On Mon, Mar 10, 2014 at 11:29 PM, James Bottomley
>> wrote:
>> >> > In the long game, though this whole debate is moot: setups with hard
>> >> > wired start times adhere to them reg
Hi,
>> This patch adds support for the APM X-Gene SoC AHCI SATA host controller
>> driver. It requires the corresponding APM X-Gene SoC PHY driver. This
>> initial version only supports Gen3 speed.
>
> This version seems workable, thanks for the quick follow-up.
>
> The comment about Gen3 speed ab
21 matches
Mail list logo
